Subj : Re: Function pointers in shm shared memory ?
To   : comp.programming.threads
From : doug
Date : Fri Apr 29 2005 06:34 pm

"CM" <c.mench@adilinstruments.com> wrote in message 
news:d4t78d$kvn$1@s1.news.oleane.net...
>
> "Joe Seigh" <jseigh_01@xemaps.com> wrote in message
> news:opspztgmmmqm36vk@grunion...
>> On Fri, 29 Apr 2005 13:01:25 +0200, CM <c.mench@adilinstruments.com>
> wrote:
>>
>> > Hello all,
>> >
>> > In the process of seekeing the most
>> > effective clientserver communication
>> > for a personal project i stumble about
>> > an idea.
>> >
>> > under linux 2.6
>> >
>> > Is it possible to share a memory segment
>> > which would contain a block of function
>> > that call inside the server process.
>> >
>> > the client after obtaining the shared memory
>> > segment would just have to call a function in
>> > shared segment to actually call a function of
>> > the server
>> >
>> [...]
>> > Any thought about this mechanism ?
>> >
>> >     Thanks
>> >
>> >
>>
>> I don't think you can get there from here.  It's not code
>> that you're trying to move between server and client, it's
>> data.
>
>    So it is not possible to call my brigde functions
> from the clients ? Can you explain why ?

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.

>
>> If you want shared code, why not use the shared
>> library mechanism?
>>
>    because my server process cannot exist in multiple
> instances, as in fact it is a process using OpenGl to
> draw things..
>
>    I seek a way to call function to my server without
> pipes, messages queues or sockets.
>
>    The best solution so far would be a shared mem variable
> that would be scrutinized by my main loop in server. but I
> wanted to avoid this sort of round robbin with much syscalls
> for the mutex handling.

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?

>
>
> thanks
>
>
>
>
>

.