Re^2: Compiling with pp on Strawberry Perl on Windows with threads fails

I tried your version, and it does work running just the perl on Windows 7 with Strawberry Perl

This is perl 5, version 24, subversion 0 (v5.24.0) built for MSWin32-x64-multi-thread

Running with pp also works to create the exe file

pp -x ThreadTest2.pl -o ThreadTest2.exe

But when running the created executable, it gets the same popup error as my version.

ThreadTest2.exe has stopped working

I've been told by other co-workers that this "behavior" is also seen with pp on ActiveState perl and with Perl2Exe compiler, though I haven't tested those. Still scratching my head.

Comment on Re^2: Compiling with pp on Strawberry Perl on Windows with threads fails

Replies are listed 'Best First'.
Re^3: Compiling with pp on Strawberry Perl on Windows with threads fails by NetWallah (Canon) on Jul 08, 2016 at 19:03 UTC
This sample code shows the author using a "select" to "sleep", after invoking "fork". Other Internet postings also indicate the need for sleep after fork, on Windows. Could you try adding a "sleep 1;" after the fork, to see if that helps ? (I am having trouble installing a working PAR::Packer). There is no time like the present for postponing what you ought to be doing.	[reply]
Re^4: Compiling with pp on Strawberry Perl on Windows with threads fails by naudefj (Initiate) on Jul 10, 2016 at 20:03 UTC
I have the same problem, fork() works perfectly fine until you compile the code with pp and run the executable. I've added a sleep() as suggested above, but it did help.	[reply]
Re^5: Compiling with pp on Strawberry Perl on Windows with threads fails by Anonymous Monk on Jul 10, 2016 at 20:39 UTC
fork does not work fine on windows, read perlfork when run outside of par on windows this test program doesn't run 50 threads 1 at a time when run after being par packed, the output is exactly the same as when run outside of par, except after the program ends/exits there is a memory violation so fork works just the same on win32 inside/outside of par, the memory violation message can be quieted with `use Win32API::File(); Win32API::File::SetErrorMode(2);` I didn't scrutinize the OPs code to see if has logic errors because If you're going to be calling the code "threads" this might as well use real threads , its is much better on win32 than fork	[reply] [d/l]