[LAD] Inter thread Communication: Design Approach

Paul Davis paul at linuxaudiosystems.com
Sun Sep 4 00:45:48 UTC 2011


On Sat, Sep 3, 2011 at 8:42 PM, Paul Davis <paul at linuxaudiosystems.com> wrote:
> On Sat, Sep 3, 2011 at 5:25 PM, Fons Adriaensen <fons at linuxaudio.org> wrote:
>> On Fri, Sep 02, 2011 at 07:50:17AM -0400, Paul Davis wrote:
>>
>>> 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).
>>
>> Mmm. Did you ever look at what's going on behind the scenes
>> (/usr/include/boost/function/function/function_base.hpp) ?
>>
>> Calling a void function(void) is a basic language operation,
>> supported directly by most CPU instruction sets and normally
>> translating into just a few CPU instrunctions.

btw, i also feel that you may have missed the point of the declaration
of boost::function<void()>

it does NOT mean that the function that will be executed by operator()
of the boost::function is a void function(void). it means that
operator() can be called without arguments and does return a result.
the actual function executed may take any number of arguments that
will be marshalled from within the functor itself.

its very easy to write a super-fast functor in C++ - i've done one
that barely ends up with any more instructions than a direct function
call. this does not, alas, translate into something usable in all the
ways that things like sigc::mem_fun or boost::function are. the
complexities become more apparent once you try an implementation
yourself.



More information about the Linux-audio-dev mailing list