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