Re: [LAD] LAD] RT-Safe UI/Engine Decoupling using Functional

On 08/07/2011 12:06 AM, Florian Paul Schmidt wrote:
> On 08/07/2011 12:03 AM, Florian Paul Schmidt wrote:
>> I guess though, that one could try a little dirty hack parsing the
>> symbol table of the target process to simplify lookup of functions to
>> call. Assume you want to be able to just send the rendering process a
>> command via the network, like
>>
>> ["/filter_set_frequency", 1, 0.2]
>>
>> (assuming OSC style commands)
>>
>> meaning: call the function filter_set_frequency with the arguments 1
>> and 0.2. where 1 is the number of the filter and 0.2 the frequency..
>> The rendering process would have a non-RT thread in which it receives
>> network commands. The receiver process could parse the output of a
>> dlsym function call on itself to get a function pointer to the
>> function filter_set_frequency. Then it would use a boost::bind object
>> to bind the arguments to it and pass this functor as command to the
>> RT thread of the rendering process. No explicit hacking of command
>> tables or what not, would be needed.. Member function handling would
>> be a bit more difficult. I have to think about this a bit..
>
> Actually, type safety would go out of the window, as the signature of
> a function is not really apparent from the symbol table. So some
> caution would have to be used when sending commands, making sure that
> the types of arguments are right. Before creating the boost::bind
> functor the raw function pointer from dlsym would have to be cast to
> the right type.. Maybe boost::bind would be the wrong approach here
> alltogether.. Will need to think about it a bit more..

OMG, could this be the one single place where polish notation would have
a place? To clarify: Encode the signature of functions in the name of
the function and restrict yourself to several function signatures that
cover the kind of functions you want to expose. Then you could cast into
the appropriate type and again use boost::bind..

Ugly, am I on crack? Who knows? Going to party now. Laters,

Flo
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Sun Aug 7 04:15:02 2011