in reply to Multi Threading in PerlApp generate using perl2exe

I don't think you can do this in the manner you're expressing... Since the first file is technically still executing (with a system or fork command) the second file, the OS will (usually) be smart.

You could try to exec the second file in the first one and then exit the first, as it's supposed to fire and not worry about returning. Then your second file could unlink the first one, but I think that's the wrong approach too.

Were I in your shoes, I'd consider a THIRD file to manage the execution of the first two. That way you don't have to jump through any hoops in coping with OS locking. Having that third file self-delete is going to be host related each time, or the second file could remove the management script at some point.

Replies are listed 'Best First'.
Re^2: Multi Threading in PerlApp generate using perl2exe
by Anonymous Monk on Nov 19, 2013 at 05:47 UTC
    Thanks for your reply, will try that way i.e to write a third file to manage two files. However just for information, I am trying to simuilate the application synchronization using perl, where everytime an application is launched it will download the config file first and will check is there is version mismatch of local copy with that of the repository copy(which is uploaded on some webpage) and if there is a mismatch it will download the newer version. I am bit afraid having the third file will slove this issue as I may need to launch the third file from the first exe.
      Assuming you can easily get a version number from your source, have your script take an option that can get it to dump it's version number. GetOpt::Long is exceptionally good for this. Depending on the specifics, you may be able to get back down to two files.