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

> In any case, fork and wait* on
> Windows is a minefield.

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.

> What do you mean by "compile a perl script in exe"?

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