Re: [LAD] Inter thread Communication: Design Approach

On Thu, Sep 1, 2011 at 7:18 PM, David Robillard <d@email-addr-hidden> wrote:

> The main issue you'll find with going the C++/RTTI route is that #2 no
> longer is possible, since virtual objects are not POD, so you can't
> safely write them through a ringbuffer (or copy them around manually in
> general).

True, I'm currently just adding functions to an existing class, rather than
the subclassing option. That makes reading / writing the class to/from a
ringbuffer easier, as they're all the same size... For performance I'm aware
that its causing extra work, but for simplicity I'm going to keep it this
way :D

The uglest bit of having one class is having a fixed amount of variables,
and only some are being used. I've circumvented madness by creating set()
functions, that initialize the "type" variable, and also takes the right
parameters for that event type & stores them in the class. Does mean that
there's some pointless data being transferred into / outta the JACK thread
using the ringbuffers... oh well!

You can, of course, copy around *pointers* to them. This means you have
> to dynamically allocate them. If you want to be able to create events in
> a real-time thread, you will have to get into more advanced C++ and make
> a custom allocator for that etc. etc.
>

Pointers: That's exactly what I'm doing... and I do need to dynamically
allocate them too... so I decided to do that in a non-RT thread, and have a
ringbuffer of new events, and a ringbuffer of valid events, where the JACK
RT thread can pull one of the Events from the "store" of new events, and
then fill it in in a RT context, and then push that pointer onto the other
ringbuffer that's going to be processed in another non-RT context... It
might be a little more complex than needed, but its serving my purposes now
:)

Passing strings around isn't possible due to the nature of strdup(), so I've
enumerated all the messagesthat the JACK thread might need to send, and then
have a big switch to handle all the different error messages. Not very nice
but its RT safe. I've done the same for sending the PATH and SIGNATURE
elements of OSC messages.

Functors & closures, yeah I suppose... for now this system is working, and
quite easy to add new types to (does need a big recompile after a change
though.. as heaps of headers include the "Event" type, as its pretty much to
core of the Engine.. :)

-Harry

PS: Nice article on "Duct tape programming":
http://www.joelonsoftware.com/items/2009/09/23.html Especially read the
paragraph beside the photo of the guy jumping

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Fri Sep 2 00:15:03 2011