process communication design (c++ <-> perl)

[Hannes]

Hi,

I'm trying to find a better design for communication between a c++ and a
perl/Tk program (processes running at the same time).

Both processes show some graphical content in a window.
If the perl/Tk process updates the view (by user interaction) the c++
program should do so also (immediately) and vice versa.
The values of some variables have to be exchanged.

Formerly I tried this with an SysV IPC shared memory block, which contains
the value of some variables. The "signal" to the other process to update
was implemented via signals (e.g. SIGUSR2). This works fine for the one
direction (perl->c++) but not for the other way due to some "property" of
safe signal handling (in Perl) and Tk MainLoop (see topics: "Tk +
perl-5.8.0 eat and delays signals" and the recent thread "Toplevel doesn't
update").

While trying to find the best design for such a task a few things should be
considered:
1) The production environment: Perl 5.8, Tk 800.024
2) Preferably the solution should be platform independent
3) and (of cause) fast and safe.

Has anybody a good idea? Or tried something similar with success?
Any ideas are welcome...


Thanks
Hannes


PS: I posted this on comp.lang.perl.tk before, but since its not really
related to perl/Tk I think this is the better place.

 

[Ben Morrow]

I'm trying to find a better design for communication between a c++ and a
perl/Tk program (processes running at the same time).

Both processes show some graphical content in a window.
If the perl/Tk process updates the view (by user interaction) the c++
program should do so also (immediately) and vice versa.
The values of some variables have to be exchanged.

Formerly I tried this with an SysV IPC shared memory block, which contains
the value of some variables. The "signal" to the other process to update
was implemented via signals (e.g. SIGUSR2). This works fine for the one
direction (perl->c++) but not for the other way due to some "property" of
safe signal handling (in Perl) and Tk MainLoop (see topics: "Tk +
perl-5.8.0 eat and delays signals" and the recent thread "Toplevel doesn't
update").

I would use sockets for this, either Unix-domain or inet-domain.

Ben

 

[kz]

I would use sockets for this, either Unix-domain or inet-domain.

Ben

I was doing something similar.
I created a very primitive TCP server application (using a listening socket
and select() ) which was receiving data from processes A, B,..... etc and
broadcasting this data back to all processes. Something like a chat server.
You might want to check out the POE cookbook at
http://poe.perl.org?POE_Cookbook which has various good examples.
Specifically, http://poe.perl.org/?POE_Cookbook/Chat_Server does the same
thing I described previously, but in a more elegant way.

If you decide to go this way, you will have to modify your c++ code to
connect to your "chat server" at startup, send the relevant changes to the
server as soon as they occur, monitor the TCP connection for any incoming
data and update themselves as requested. I used Net::Telnet in my clients to
connect to the "chat server". Also, in real life make sure your "chat
server" is alive when you start your other stuff...

HTH,

Zoltan Kandi, M. Sc.

 

[Hannes]

How often do you need to update the screen? And what latency can you
live with? If not too fast, I would put a counter in shared memory and
increment it everytime shared memory was updated. You can have each
process poll the counter every second, compare the current value in
shared memory with the previous value fetched, and fetch the values in
shared memory when the counter changes.

Are you using a locking mechanism to protect shared memory from
concurrent access? Something like semaphores?

I used the above scheme very successfully, but didn't need really fast
update rates. The screens were changing every 10-15 seconds or so, and
a fraction of a second latency was OK.

Thanks for the answer...
Since this is some graphical application, the update rates should be as fast
as possible. (The Perl-script is some sort of analysing tool, the c++ part
shows simultaneously a openGL 3D view).

Hannes