On Sun, Feb 17, 2013 at 4:41 PM, Harry van Haaren <[email protected]> wrote: > > > On Sun, Feb 17, 2013 at 9:20 PM, Paul Coccoli <[email protected]> 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.
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? > 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. 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. > 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. >> >> 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. > _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
