Tomas Doran wrote:
Matthew Knopp wrote:
Interestingly I can "fix" the problem by setting PAR_CLEAN=1. A
This also fixes the problem I was having with Class::DBI that I reported
to the list a week or two ago.
Is there any easy way to set the PAR_CLEAN variable from within my
module(s) so that PAR picks it up?
I tried a dumb: $ENV{PAR_CLEAN} = 1; at the top of my module, this gave
me no joy..
I also tried the more devious (but equally fruitless):
use PAR;
package PAR;
local $ENV;
$ENV{PAR_CLEAN} = 1;
package MyPackage;
which has the same lack of effects.
An alternative would be to specify clean: 1 in my Meta.YAML file for my
module .par files, however:
a) I can't do that and trivially build modules with par.pl -p (as it
doesn't support this feature)
b) That is overridden by PAR_CLEAN anyway..
Any hints (or fix to the root cause) would be appreciated ;)
Cheers
Tomas
The statement below
$ENV{PAR_GLOBAL_CLEAN} = 1;
is copied from a test in
...PAR-0.89\contrib\automated_pp_test\automated_pp_test.pl
where such things get a little bit of testing.
Unfortunately this is not the $ENV{PAR_CLEAN} you are discussing, so it
may not stop the infinite loop. If all else fails you may want to try
it anyway. There is also the -C flag, as in
system pp -C -o foo foo.pl
If you do try it, here is part of a pasted note from the said file:
# Notes: PAR_GLOBAL_CLEAN overides -C. If you set
# PAR_GLOBAL_CLEAN to 1 or 0, -C doesn't do anything.
# If -C does work, it creates temp-pid dirs, ...
I hope the -C and/or the PAR_GLOBAL_CLEAN thing works. At least until a
real fix comes along.
