http://www.perlmonks.org?node_id=847977

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

Dear Monks,

I have a general question regarding the possibility to share variables between two different applications written in Perl (with GUI) and compiled exe.

I'am searching for the possibility to pass a variable (simple value, for example a word) from app 1 to app 2, maybe triggering some subrutine in app 2.

I could bring the 2 perl.pl scripts together in one script (or use modules) and compile one exe. This would mean a lot of work rewriting parts of the 2 scripts.

Any other possibility/idea worth spending time working on?

Thank you very much for your suggestions.

Cla

Replies are listed 'Best First'.
Re: Sharing variables between applications
by Corion (Patriarch) on Jul 04, 2010 at 12:11 UTC

    See perlipc.

    As IPC usually is a nasty thing, I recommend using a database or a directory as a communication device. This means both of your programs need to poll the shared structure for new messages arriving.

    You could also use a TCP socket for communication, but that means you will need to ensure that the port used is not occupied by another program.

    Potentially also see AnyEvent::MP for a way to send messages between programs.

Re: Sharing variables between applications
by sflitman (Hermit) on Jul 04, 2010 at 12:08 UTC
    Why not send a command line argument to app2?
    system 'app2.pl word';
    Alternatively you could set an environment variable:
    system "X=word; app2.pl";
    and app2 would have to look for it in %ENV

    HTH,
    SSF

Re: Sharing variables between applications
by graff (Chancellor) on Jul 04, 2010 at 16:32 UTC
    I'm confused by your description. I understand that you have two perl apps that run independently -- Do they both have GUIs? Your opening sentence also mentions a "compiled exe" (so I gather you are using ms-windows) -- How does this relate to the two perl apps? Do you generally (or sometimes) use each app independently, or are they always used in combination (because they are interrelated / interdependent)?

    Here's a suggestion, based on a wild guess about what you are trying to describe. If app2 will continue to be useful on its own as a GUI, and a particular subroutine in app2 does what is needed in app1, then the simplest thing would be to isolate that subroutine as a module (along with anything else it needs to do its job), so that both app1 and app2 can use it, without getting bogged down in IPC issues (which tend to be a little trickier when applied to scripts that have GUIs).

      Thank you all for your suggestions

      @graff: the two (GUI) applications are two different piece of software doing two different things. They are generally used indipendently from each other. As things grow up, I notice they could share some data. Example: App1 is an interface to a SQlite database. Just managing various data. App2 elaborates statistical alalysis from texts. Just thought it nice, if I could "bring togheter" the two things: For example doing some statistical data in App2 starting from a query result in App1.

      By now I think the easiest thing to do is use a exchange-database or something like that, as suggested in a reply.

Re: Sharing variables between applications
by Proclus (Beadle) on Jul 04, 2010 at 20:06 UTC
    I have many wxPerl applications running exes and communicating with windows services.

    When dealing with GUIs, in addition to our inter communication needs,we worry about blocking issues. To solve these two problems, I find the POE framework very helpful.

    You can have a look at these modules in CPAN:
    POE::Wheel::Run
    POE::Wheel::SocketFactory
    POE::Wheel::ReadWrite
    POE::Wheel::FollowTail

    The last module, FollowTail, could be the easiest to implement for you. The GUI can listen to a file which is being written by some other exe. Everytime you get a new line, a callback is triggered so you get a very good asynchronous behavior.
Re: Sharing variables between applications
by JavaFan (Canon) on Jul 05, 2010 at 10:26 UTC
    There are various ways two (Unix) processes can exchange information, depending on the needs, and how (or when) they are started. Say, process A wants to send information to process B. Some options are:
    • Signals. Con: only one bit of information can be send. Both processes need to be running at the same time. And process A needs to have the appropriate permission to send a signal.
    • Environment variables. Con: This requires process A to be (great)*parent of process B in the process tree.
    • Command line arguments. Con: process A needs to be the parent of process B.
    • Pipe. Pro: bidirectional communication is possible. Con: synchronisation is harder. Deadlock may occur.
    • Shared memory. Pro: can exchange complex values. Data can be shared among multiple processes. Data can live past the life time of the process. Con: Many programmers find it hard to do it right. Often requires use of semaphores. May be hard to carry over to a different platform. Data can live past the life time of the process.
    • Local external resources (files, for instance). Pro: Processes don't need to run at the same time. Con: Needs synchronisation (locking). Need to take care files get removed.
    • Non-local external resources (databases, for instance). Pro: Processes don't need to run at the same time, or even on the same machine. Con: Requires setting up the external resource, which may be costly. It's far from being the simplest or fastest solution.
    And then I probably forgot a few.