Subj : Re: Function pointers in shm shared memory ?
To   : comp.programming.threads
From : doug
Date : Sat Apr 30 2005 12:38 pm


"red" <red@localhost.localdomain> wrote in message 
news:pan.2005.04.29.20.44.54.56295@localhost.localdomain...
>>>    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.
>
>
>
>

Again, just off the top of my head, I can't see how you would do that.  You 
have two seperate processes - you cannot get a thread from the client 
process to run server process code/access server process data.  (As far as I 
know.)  You'll have to resort to standard IPC - pipes, sockets or shared 
memory.  Shared memory will be fastest, I believe.

.