17 Feb
2013
17 Feb
'13
11:03 p.m.
On Sun, Feb 17, 2013 at 4:41 PM, Harry van Haaren <harryhaaren(a)gmail.com> wrote:
My suggestion has nothing to do with mem-pools or placement new. That
depends on your memory management strategy, which is orthogonal to
this discussion.
On Sun, Feb 17, 2013 at 9:20 PM, Paul Coccoli <pcoccoli(a)gmail.com> wrote:
But you're not guaranteed to write that many bytes at a time. If the
write of a chunk of bytes (your event object) to a ringbuffer wraps,
you probably wind up with two writes. A read from another thread may
get an incomplete object. What happens then?
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-App…).
This seemed to be the best simple RT safe solution. If you have suggestions
/ improvements I'd love to hear them.
I did make a suggestion.
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.
Indeed, that would be necessary. Again, more complications. That said, it
can be done,
and would involve less "traffic" trough the ringbuffer, and also "fixed
size" traffic": pointers to EventBase.