On Sun, Feb 17, 2013 at 4:41 PM, Harry van Haaren <harryhaaren@email-addr-hidden> wrote:
>
>
> On Sun, Feb 17, 2013 at 9:20 PM, Paul Coccoli <pcoccoli@email-addr-hidden> 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
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Mon Feb 18 00:15:05 2013
This archive was generated by hypermail 2.1.8 : Mon Feb 18 2013 - 00:15:06 EET