On Mon, Dec 17, 2012 at 3:45 PM, Amit Dev <amit...@gmail.com> wrote: > We have a perl program packaged into a par. The par is executed and it >
By "program packaged into a par" do you mean a standalone executable created with "pp -o some.exe script.pl" or a .par file created with "pp -p -o some.par script.pl" (that you run with "perl -MPAR=some.par ...")? > Sometime we shutdown the process and run it again or run an > updated copy of the par file. And intermittently it fails with "Compilation > error..." in logs. > Looks like the issue is somewhere within temp folder (par-root/cache-*). > Once the issue happens I see a "inc.lock" folder created within. Not sure > how the whole thing works. > For the case of the standalone executable: If you run it for the first time (i.e. /tmp/par-USER/cache-DIGEST doesn't exit), this cache directory is created and some stuff (a custom perl interpreter, modules, DLLs, data files) is extracted from the executable into it. Then the custom perl interpreter is executed, finally running the original script. The next time you run the same executable (as the same user, as the cache directory is per-user) we see that the cache directory already exists, so the extraction phase is skipped and the perl interpreter is executed right away. Actually that's the simplified version - what happens if the first and second invocations happen in rapid succession, so that the first is still extracting stuff while the second is started? So the actual criterion for "stuff has completely been extracted (hence we may skip extraction)" is "does /tmp/par-USER/cache-DIGEST/inc exist". If not, acquire some kind of lock, create .../inc, extract stuff and release the lock. Acquiring the lock here is implemented as "mkdir .../inc.lock" (successfully) and releasing it is "rmdir .../inc.lock" (probably because mkdir is the only portable atomic file operation). Cheers, Roderich If you update the executable it should get a different hash DIGEST and hence the cache directory shoudl be different, so no problem here.
