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

Discussion in 'Perl Misc' started by Hannes, Mar 2, 2004.

  1. Hannes

    Hannes Guest

    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.
    Hannes, Mar 2, 2004
    #1
    1. Advertising

  2. Hannes

    Ben Morrow Guest

    Hannes <> wrote:
    > 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

    --
    Every twenty-four hours about 34k children die from the effects of poverty.
    Meanwhile, the latest estimate is that 2800 people died on 9/11, so it's like
    that image, that ghastly, grey-billowing, double-barrelled fall, repeated
    twelve times every day. Full of children. [Iain Banks]
    Ben Morrow, Mar 2, 2004
    #2
    1. Advertising

  3. Hannes

    kz Guest

    "Ben Morrow" <> wrote in message
    news:c21se0$g8s$...
    >
    > Hannes <> wrote:
    > > 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


    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.
    kz, Mar 2, 2004
    #3
  4. Hannes

    Hannes Guest


    > 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
    Hannes, Mar 3, 2004
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Knute Johnson
    Replies:
    0
    Views:
    827
    Knute Johnson
    Jun 27, 2003
  2. Jon A. Cruz
    Replies:
    0
    Views:
    733
    Jon A. Cruz
    Jun 28, 2003
  3. Sudsy
    Replies:
    0
    Views:
    959
    Sudsy
    Jun 28, 2003
  4. Frank D. Greco
    Replies:
    1
    Views:
    2,206
    Keeger
    Jun 30, 2003
  5. Harald Kirsch
    Replies:
    1
    Views:
    350
    Michael Borgwardt
    Jan 8, 2004
Loading...

Share This Page