On Sun, Feb 17, 2013 at 9:20 PM, Paul Coccoli <pcoccoli@gmail.com> wrote:

This scheme sounds error prone. In general, copying C++ objects via
memcpy (or writing them 1 byte at a time into the ringbuffer, which is
what I think you're proposing) is a bad idea.

Nope, write them one sizeof( event->size() ) at a time.
I'm very interested in why copying C++ objects like this is a bad idea.
Its been discussed on list before (http://linux-audio.4202.n7.nabble.com/Inter-thread-Communication-Design-Approach-td68710.html).
This seemed to be the best simple RT safe solution. If you have suggestions / improvements I'd love to hear them.

JACK ringbuffers are
ideally suited to passing simple types (like floats), and not vairable
sized things (like different derived Event classes). Your enum for
event types is a bit of a red flag, too. While its perfectly valid,
"type flags" like this more often than not accompany inflexible,
tightly coupled code (which may be fine in a small audio app, but few
apps stay small).

What about passing pointers via the ringbuffer?

Pointers to an Event? Just makes it more hassle to send an Event from the RT thread.
Involves taking X memory from a mem-pool, and then using placement new to construct
the EventPlay(), and then send the pointer trough the ringbuffer. More complicated IMO.

To free the event objects, you could pass them back via a second ringbuffer so the RT
threads aren't responsible for deleting them.