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
