Prevent multiple instances of a script to launch

Discussion in 'Perl Misc' started by Philipp, Aug 25, 2006.

  1. Philipp

    Philipp Guest

    Hello
    I have written a Perl script (win32) and use it to drag&drop files on it
    for execution.
    Now if I drop multiple files at once, they are processed one after the
    other. But if I drop one file at a time, each starts a new perl
    interpreter and new script.

    Is there an easy way to prevent these new copies to start and instead
    queue the corresponding files in an already running script? (so they get
    executed sequentially and not in parallel)

    Thanks for your answers
    Phil
    Philipp, Aug 25, 2006
    #1
    1. Advertising

  2. Philipp

    -berlin.de Guest

    Philipp <> wrote in comp.lang.perl.misc:
    > Hello
    > I have written a Perl script (win32) and use it to drag&drop files on it
    > for execution.
    > Now if I drop multiple files at once, they are processed one after the
    > other. But if I drop one file at a time, each starts a new perl
    > interpreter and new script.
    >
    > Is there an easy way to prevent these new copies to start and instead
    > queue the corresponding files in an already running script? (so they get
    > executed sequentially and not in parallel)


    The standard method is for the program to acquire an exclusive lock
    on some (fixed) file before starting to work. That serializes the
    processes. I don't know how well file locking works on win32.

    Anno
    -berlin.de, Aug 25, 2006
    #2
    1. Advertising

  3. Philipp

    Philipp Guest

    -berlin.de wrote:
    > Philipp <> wrote in comp.lang.perl.misc:
    >
    >>Hello
    >>I have written a Perl script (win32) and use it to drag&drop files on it
    >>for execution.
    >>Now if I drop multiple files at once, they are processed one after the
    >>other. But if I drop one file at a time, each starts a new perl
    >>interpreter and new script.
    >>
    >>Is there an easy way to prevent these new copies to start and instead
    >>queue the corresponding files in an already running script? (so they get
    >>executed sequentially and not in parallel)

    >
    >
    > The standard method is for the program to acquire an exclusive lock
    > on some (fixed) file before starting to work. That serializes the
    > processes. I don't know how well file locking works on win32.


    If I understand this correctly, this will start a second interpreter but
    it will wait until the lock of the first is released? This is not
    exactly the behavior that I want.
    I would like all files to be processed by the same interpreter instance.
    This means that a second instance would need to:
    - check somehow if a first one is already running (eg. with a lock?)
    - add files to the queue of first instance (how?)

    For the second point I can imagine a method like writing a queue to a
    file but probably writing to some stack in memory is better/faster. How
    could I do this? How can you make two scripts share a piece of memory?

    If you could point me to some documentation or even better som existing
    code somewhere, I would be very grateful.

    Phil
    Philipp, Aug 25, 2006
    #3
  4. Philipp

    -berlin.de Guest

    Philipp <> wrote in comp.lang.perl.misc:
    > -berlin.de wrote:
    > > Philipp <> wrote in comp.lang.perl.misc:
    > >
    > >>Hello
    > >>I have written a Perl script (win32) and use it to drag&drop files on it
    > >>for execution.
    > >>Now if I drop multiple files at once, they are processed one after the
    > >>other. But if I drop one file at a time, each starts a new perl
    > >>interpreter and new script.
    > >>
    > >>Is there an easy way to prevent these new copies to start and instead
    > >>queue the corresponding files in an already running script? (so they get
    > >>executed sequentially and not in parallel)

    > >
    > >
    > > The standard method is for the program to acquire an exclusive lock
    > > on some (fixed) file before starting to work. That serializes the
    > > processes. I don't know how well file locking works on win32.

    >
    > If I understand this correctly, this will start a second interpreter but
    > it will wait until the lock of the first is released? This is not
    > exactly the behavior that I want.


    Right. That's often good enough.

    > I would like all files to be processed by the same interpreter instance.
    > This means that a second instance would need to:
    > - check somehow if a first one is already running (eg. with a lock?)
    > - add files to the queue of first instance (how?)


    That amounts to a sever-client model. There is a lot of literature
    about that (start with perlipc) and lots of CPAN modules that support
    that model.

    You'll need some form of IPC to transmit requests to the server. The
    server could be started on demand and quit when there is nothing to do,
    or it could be started once and keep running (other possibilities exist).
    Again, file locking is the safest way of keeping multiple instances
    of the server from running, but the server doesn't wait for the lock,
    it tests the lock non-blocking and just quits when it can't get it.

    Anno
    -berlin.de, Aug 25, 2006
    #4
  5. Philipp

    Philipp Guest

    -berlin.de wrote:
    > That amounts to a sever-client model. There is a lot of literature
    > about that (start with perlipc) and lots of CPAN modules that support
    > that model.
    >
    > You'll need some form of IPC to transmit requests to the server. The
    > server could be started on demand and quit when there is nothing to do,
    > or it could be started once and keep running (other possibilities exist).
    > Again, file locking is the safest way of keeping multiple instances
    > of the server from running, but the server doesn't wait for the lock,
    > it tests the lock non-blocking and just quits when it can't get it.


    OK thanks. I will look into that (although it looks way out of my
    programming skills...)
    Phil
    Philipp, Aug 25, 2006
    #5
  6. Philipp

    Dr.Ruud Guest

    Philipp schreef:

    > I have written a Perl script (win32) and use it to drag&drop files on
    > it for execution.
    > Now if I drop multiple files at once, they are processed one after the
    > other. But if I drop one file at a time, each starts a new perl
    > interpreter and new script.
    >
    > Is there an easy way to prevent these new copies to start and instead
    > queue the corresponding files in an already running script? (so they
    > get executed sequentially and not in parallel)


    The new copy should check whether there is an older copy running, and
    then hand over its job-data to that older copy. You could use POE.

    --
    Affijn, Ruud

    "Gewoon is een tijger."
    Dr.Ruud, Aug 25, 2006
    #6
  7. Philipp wrote:
    > Hello
    > I have written a Perl script (win32) and use it to drag&drop files on it
    > for execution.
    > Now if I drop multiple files at once, they are processed one after the
    > other. But if I drop one file at a time, each starts a new perl
    > interpreter and new script.
    >
    > Is there an easy way to prevent these new copies to start and instead
    > queue the corresponding files in an already running script? (so they get
    > executed sequentially and not in parallel)
    >


    One possible solution would be to write the files to a simple DBM and
    delete DBM entries as the files are processed. The "master" instance
    would do the processing after locking a sentinel file to prevent a
    possible "master" race condition Subsequent "helper" instances of the
    script would detect the lock and just add their files to the DBM before
    exiting. The master could check for running helpers when the DBM emptied
    out. Then, if helpers were still running, the master could sleep/loop
    checking for DBM additions; if no helpers were running and the DBM was
    empty, the master could unlock the sentinel and exit.


    hth,
    --
    Charles DeRykus
    Charles DeRykus, Aug 25, 2006
    #7
    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. John Wohlbier
    Replies:
    2
    Views:
    355
    Josiah Carlson
    Feb 22, 2004
  2. Andreas Leitgeb
    Replies:
    2
    Views:
    361
    Andreas Leitgeb
    Jul 10, 2008
  3. RyGa
    Replies:
    0
    Views:
    240
  4. Replies:
    8
    Views:
    444
    James Stroud
    Jan 29, 2009
  5. Nav
    Replies:
    15
    Views:
    543
    Steven D'Aprano
    Jan 5, 2010
Loading...

Share This Page