[rt.cpan.org #132398] PAR::Packer and fork

Wed Apr 22 08:13:31 2020: Request 132398 was acted upon.
Transaction: Ticket created by [email protected]
Queue: PAR-Packer
Subject: PAR::Packer and fork
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: [email protected]
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=132398 >


Bonjour,

le binaire réaliser par pp ne fonctionne pas lorsque fork est utilisé

Version perl : perl 5, version 28, subversion 2 (v5.28.2) built for
MSWin32-x86-multi-thread-64int

Windows 10 64Bits

fichier utilisé :

> use strict;
> use warnings;
> use diagnostics;
> use 5.010;
>
> my $name = 'Foo';
>
> say "PID $$";
> my $pid = fork();
> die if not defined $pid;
> if (not $pid) {
>    say "In child  ($name) - PID $$ ($pid)";
>    $name = 'Qux';
>     sleep 2;
>    say "In child  ($name) - PID $$ ($pid)";
>    exit;
> }
>
> say "In parent ($name) - PID $$ ($pid)";
> $name = 'Bar';
>  sleep 2;
> say "In parent ($name) - PID $$ ($pid)";
>
> my $finished = wait();
> say "In parent ($name) - PID $$ finished $finished";
sortie :

> PID 9400
> In parent (Foo) - PID 9400 (-9928)
> In child  (Foo) - PID -9928 (0)
> In parent (Bar) - PID 9400 (-9928)
> In child  (Qux) - PID -9928 (0)
> In parent (Bar) - PID 9400 finished -9928
pack : pp -c -x fork.pl -o fork.exe

sortie :

> PID 8384
> In parent (Foo) - PID 8384 (-4572)
> In child  (Foo) - PID -4572 (0)
> In parent (Bar) - PID 8384 (-4572)
> In child  (Qux) - PID -4572 (0)
La gestion des fork ne fonctionne pas, fin prématuré de l'exe suivit
egalement des erreurs Windows

Y a t'il une solution pour utiliser fork ou d'autre module comme
POE::Wheel::Run ou Paralle::Loop ,

Tous les modules utilisant fork pose problème.

Wed Apr 22 09:14:05 2020: Request 132398 was acted upon.
Transaction: Correspondence added by RSCHUPP
What's the error message?

Try replacing the wait call with waitpid.
Note: the Windows version of PAR::Packer is special: the custom Perl interpreter
runs as (spawned) child of the bootstrap process, while on *nix Perl is
exec'ed by bootstrap.

Cheers, Roderich

Wed Apr 22 11:22:03 2020: Request 132398 was acted upon.
Transaction: Correspondence added by [email protected]
Queue: PAR-Packer
Subject: Re: [rt.cpan.org #132398] PAR::Packer and fork
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=132398 >
Changement de la source en :
> #my $finished = wait();
> my $finished = waitpid -1, 0;
C'est la même chose, se termine avant d’exécuter la ligne
sans message d'erreur

Wed Apr 22 11:49:39 2020: Request 132398 was acted upon.
Transaction: Correspondence added by RSCHUPP
Queue: PAR-Packer
Subject: PAR::Packer and fork
What about

my $finished = waitpid($pid, 0);

Please switch to English.

Cheers, Roderich

Wed Apr 22 12:04:49 2020: Request 132398 was acted upon.
Subject: Re: [rt.cpan.org #132398] PAR::Packer and fork
The modification gives the same thing the executable ends prematurely

Thu Apr 23 12:09:26 2020: Request 132398 was acted upon.
is there a way to use PAR :: Packer with a module using fork like poe ::
wheel :: run or Parallel :: ForkManager or simply by using the perl fork
command. Or pierce another way to compile a perl script in exe Thank you
for your help.

Sat Apr 25 07:00:18 2020: Request 132398 was acted upon.
Transaction: Correspondence added by RSCHUPP
Queue: PAR-Packer
Subject: PAR::Packer and fork
Dunno. The difference in behaviour of your sample script in "normal"
and pp'ed versions is definitively a bug, but I have no means
(i.e. no Windows) to investigate it. In any case, fork and wait* on
Windows is a minefield.

You might also ask for help on the PAR mailing list, [email protected]
(no registration required).
What do you mean by "compile a perl script in exe"?

Cheeers, Roderich

I agree. The fundamental difference of how fork() has to be implemented
on Windows (since it doesn't natively exist in the OS) simply makes a
lot of things weird. It's a pseudoprocess, using an OS thread in the
same process. This will simply trip some things up as threads and fork
aren't the same thing.

*Some* things can work, but other things will just behave in a way that
is hard to or impossible to work around. I've recently had to port old
code that uses fork extensively together with XML::LibXML and there's a
lot to massage there. In particular I think is the fact that you
eventually reach a part in your 'fork' that does an exit() call, which
supposedly should work correctly (and not bring the whole process down),
but I'm assuming that it triggers something that, at least with
XML::LibXML, isn't cool. The XML parsing part just dies 'somewhere'.

Also, depending on the Perl version things may happen. In my case I
initially only had an ancient 5.8.9 to work with, and something in the
forking code upset the interpreter so it always died with a core crash
when exiting (with a nasty 'your process crashed bla bla msgbox). Now
I've thankfully have redone so much that I'm on a 5.30 strawberry, but
forking still doesn't work with XML. Rewriting the Windows parts using
ithreads ('use threads') has made me able to workaround the XML stuff,
but the process still generates errors when exiting, printing complaints
about freeing memory that is already freed etc.

A lot of debugging of Perl and the C code in XML::LibXML might yield a
clue but I haven't the time or inclination to even try. In short, feel
free to try out fork/threads to make your particular usecase to work,
but be prepared that it most likely won't work and so don't beat your
head to the wall and accept you may need something else or just another
approach. E.g. in some cases I rewrote stuff so I generated code on the
fly, started a new Perl with that, and that process could do stuff I
can't do in 'my' process. Clumsy as hell, but...

At the end, adding pp on top of the minefield becomes a non-starter,
IMO. Sorry.

On another note however, I am **eagerly** awaiting WSL2 (i.e. 'Windows
Subsystem Linux'). The integration this will bring is unprecedented
(much better than WSL1 which was also really nice). Speculation abounds
that we might even eventually see a Linux kernel to replace the NT
kernel which would be absolutely awesome. In any case, if the
integration is as good as I can hope, you might simply be able to ignore
'Windows' as it is now and simply use the Linux subsystem instead and
still have things look equal to the end users. Just hoping, but keep it
in mind.
I'd guess looking for alternatives to pp. For many years I used
Activestate PDK that had 'perlapp' which basically does the same as pp.
It had other nifty stuff, too. However, once I went to Strawberry and
also had more reason to do things with multiple platforms, I'm using pp
instead. Don't know if they still sell the PDK.

ken1