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

[Florian Paul Schmidt]

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..

Flo