Re: [LAD] Inter thread Communication: Design Approach

From: Paul Davis <paul@email-addr-hidden>
Date: Fri Sep 02 2011 - 14:50:17 EEST

On Fri, Sep 2, 2011 at 6:04 AM, Fons Adriaensen <fons@email-addr-hidden> 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@email-addr-hidden> 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.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Fri Sep 2 16:15:02 2011

This archive was generated by hypermail 2.1.8 : Fri Sep 02 2011 - 16:15:02 EEST