[LAD] Inter thread Communication: Design Approach

[Paul Davis]

On Fri, Sep 2, 2011 at 6:04 AM, Fons Adriaensen <fons at linuxaudio.org> wrote:
> On Thu, Sep 01, 2011 at 03:54:03PM -0400, Paul Davis wrote:
>> On Thu, Sep 1, 2011 at 2:37 PM, Fons Adriaensen <fons at linuxaudio.org> wrote:
>>
>> > That's assuming that the event's virtual execute() has access to
>> > all it needs. In all cases I've encountered that is not the case:
>> > the event triggers something in the context where it is received
>> > and processing it requires access to that context's data.
>> > It's a problem for which I don't know a clean C++ solution.
>>
>> depending on the exact type of thing you're talking about, isn't this
>> is place for closures, functors, etc. etc. ?
>
> Yes, but
>
> 1. I find functor syntax extremely clumsy, involving the creation of
>   a specific derived functor class (from a template class) for each
>   one you need.
>
> 2. AFAIK (using the terminology of <http://www.newty.de/fpt/functor.html>,
>   you can't have a TSpecificFunctor member in the event class and
>   initialise it, it has to be a TSpecificFunctor*. Which in turn
>   means that at the sender side you either have instances of all
>   possibly required functor classes available and assign the
>   TSpecificFunctor* in the event from one of them, or you have to
>   use new() to allocate one. The former is extremely clumsy, and
>   the latter shouldn't be done in a RT context.

i'm pretty confused by what you've written here. i use functors which
have copy semantics, and the "event" classes that contain a functor do
not contain a pointer to a functor, but a functor that is copied. this
is the base class:

	struct BaseRequestObject {
	    RequestType             type;
            bool                    valid;
            InvalidationRecord*     invalidation;
	    boost::function<void()> the_slot;

            BaseRequestObject() : valid (true), invalidation (0) {}
	};

the "type" member is still there, but differentiates between requests
that require use of the functor ("the_slot") and those that are just
an enum that can be handled with no data (e.g. telling an event
loop/thread to quit).

> What I'm missing in C++ is a built-in 'functor' type that can
> simply be assigned from any object::method, with the user being
> responsible for the existence of the object and for supplying the
> right arguments at the time the functor is called.

both boost::function and sigc::mem_fun serve these roles for me. i've
stopped using sigc::mem_fun for anything other than GUI event
callbacks because sigc++ is fundamentally not thread safe, but the
easy syntax of both these forms is similar.