Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

Communicating with a long-running process

by Marcello (Hermit)
on Jan 27, 2006 at 14:35 UTC ( #525987=perlquestion: print w/replies, xml ) Need Help??

Marcello has asked for the wisdom of the Perl Monks concerning the following question:

Hello,

How do you wise monks communicate with a long-running process from another perl script which is executed by the user only? I first used signals (USR1 and USR2), but I would like to send a string so I can define multiple actions. I could write the command as a record in the database, but I do not want to poll the database too often. I could combine the database solution and sending a signal to inform to process there is a command waiting, but I prefer not using a database at all.

Currently the long-running process binds to a specific port and the other Perl script is using Net::Telnet to send commands to it.

Still, I feel there must be an easier way to sends command strings to a running process. Anyone suggestions?

Thanks!
  • Comment on Communicating with a long-running process

Replies are listed 'Best First'.
Re: Communicating with a long-running process
by tirwhan (Abbot) on Jan 27, 2006 at 15:02 UTC

    perldoc perlipc will give you lots of help and examples. If both processes are running on the same machine (and you're on a *NIX) you probably want to use a Unix domain socket instead of a TCP connection, that's both faster and simpler.

    You could also use shared memory variables for this, see IPC::Shareable and IPC::ShareLite, for example.


    There are ten types of people: those that understand binary and those that don't.
Re: Communicating with a long-running process
by BrowserUk (Pope) on Jan 27, 2006 at 15:07 UTC

    If you only want monodirectional IPC, I'd stick with the socket, but use UDP to send it. One advantage of using sockets is that if you ever want to talk to the long running process from a different box, the code need little or no modification.

    You could use shared memory. It depends which OS you are on as to which module you would need, but that's more complicated and unless you are doing lots of high speed comms, unnecessary.

    You could use Named Pipes, though I've had some problems using these from Perl on Win32 and you rarely see them mentioned for *nix.

    On win32 there are a whole raft of other options including Clipboard, COM, Data Copy, DDE, File Mapping, Mailslots, RPC and doubtless some other on *nix too; but from your description, a socket seems the easiest and most appropriate mechanism. And if you ever needed to move to a different platform, it would be the easiest to port.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
      I'd stick with the socket, but use UDP to send it

      I'm wondering why? If you issue a command to a process you'll usually want to know that the process received that command at least (as well as possibly whether the command suceeded). You can do these things over UDP but you're then essentially reimplementing TCP features. What am I missing?


      There are ten types of people: those that understand binary and those that don't.

        Your right. If confirmation of receipt is required, then stick with tcp. But I'd call that bi-directional comms and my "monodirectional IPC" clause wouldn't apply.

        Of course, you might say that since tcp is available and costs little extra in terms of programming, why not use it to get confirmation anyway. My thinking goes that it depends upon the application, but I could envisage scenarios where the long running process (hereinafter 'the server'), may not get around to checking for incoming commands until it has finished processing the last one--which could be hours or days away.

        It could also be that the command could be sent by any number of clients, but will only be acted upon once. In that scenario, what useful action would either the client or the server take if the command is a duplicate?

        1. Server: "You asked me to do X, but I've already been asked(and done) X";
        2. Client: "Oh. So you've already done, or are about to do X?";
        3. Server: "Yes.";
        4. "Okay then! So long as it gets done.";
        5. "It will."
        6. "Okay, good. So long as it does.".
        7. ""IT WILL! I just told you it would.";
        8. "Okay."
        9. "!"

        :)

        Basically what I'm trying to say there is that UDP continues to have it's place where confirmation is neither required nor useful.

        The main benefit of tcp over udp is the guarentee of delivery or error detection, but within modern LANs, and particularly with the same box, the scope for non-delivery of a UDP message is fairly small. The advantage of UDP is simply that it is quicker because it doesn't require synchronisation between the parties. If either is an advantage to the application, use it. If not, go with tcp.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://525987]
Approved by planetscape
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (5)
As of 2020-05-27 00:51 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    If programming languages were movie genres, Perl would be:















    Results (152 votes). Check out past polls.

    Notices?