Subj : Re: Function pointers in shm shared memory ?
To   : comp.programming.threads
From : red
Date : Fri Apr 29 2005 11:44 pm

>>    So it is not possible to call my brigde functions

 
> The main reason is that they're different processes, and so run in different 
> address spaces.  Unless the function (and data it uses) reside in the shared 
> memory segment, the function pointers, etc, in the 'bridge' function will 
> mean nothing to the client process, and you'll probably segfault.


You are right, I implemented quickly this some hours ago, and it segfault
when calling the bridge fct. Stupid that i didn't see that the adress
won't mean a thing for the client.


> Off the top of my head, the best thing I can think of is to implement your 
> clients as dynamically loaded libraries, and think of them as "services". 
> You instruct the server to load/unload services via some normal (slow) 
> mechanism like USR2/command_file or sockets - since actual load/unload of a 
> service won't occur much.
> Your services have a standard API (be it polling or callback (event-driven) 
> based), and run within the server process itself.  (In your example of a 
> "shared mem variable that would be scrutinized by my main loop in server", 
> your 'service' would call a callback function, which would set this flag, 
> ready for the server to catch on it's next threadcycle.  Of course, your 
> service needs to spawn its own thread on initialisation to do this (and any 
> other work it wants to do) - something you would avoid with a polling 
> interface - however, callbacks are generally nicer than polling.)
> 
> Would that fly?
> 

 I understand your proposal, and it would definitevely be interesting.
but staying with two separated processes what would be the best way to
call a function in the server ? the optimal thing for me would be to have
my server in kernel space and call it by interrupts, so what I seek is the
mechanism that would be nearly as effecient as this but in user space.

.