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
