AnyEvent::ForkManager stuck on Strawberry but not on ActivePerl?
I am not exactly sure if the difference is between Strawberry Perl and Active Perl, but it looks like it is there and I am stuck like the test of the module.
Version 0.03 of AnyEvent::ForkManager has another minor issue, you need to already have Test::Requires, which is then not used, but once you install that module, here is the main point:
On ActivePerl the test fails. See the reports
by David Solimano and
by Matt Perry.
Christian Walde also ran the tests.
OTOH on Strawberry Perl the tests get stuck as reported by Alexandr Ciornii
and later by myself.
While it would be nice if the test were passing, I think it would be also important to understand why are the tests stuck in some of the cases. Is that really some difference between Strawberry Perl and Active Perl?
ps. No, I don't really need this module, but I was smoking CPAN on Strawberry Perl and Christian Walde (Mithaldu) thinks I am just complaining and not doing anything about it.
I blog about Perl.
AnyEvent::ForkManager simply doesn't support Windows as far as I can see.
(e.g. use of signals via 'kill' on pseudo-processes created by Windows 'fork' emulation).
http://perldoc.perl.org/perlfork.html mentions a bit about this.
I think you'd need to have an expectation that the implementation should work on Windows and have it working on either ActivePerl or Strawberry before considering differences between the two distribution.
The reports by David Solimano and Matt Perry both are Strawberry Perls. I would suggest asking them if they went into task manager and killed perl processes manually.
Also note this line in my run of those tests:
It is possible that that means some kind of timeout was invoked. See: https://metacpan.org/source/DAGOLDEN/CPAN-Reporter-1.2009/lib/CPAN/Reporter.pm#L528
I disagree. If the author knows that a distribution cannot possibly work on a certain platform they should mark it appropiately, cancel early in the make phase and spare CPAN testers the pain of having to babysit their smoker in case a dist manages to freeze up.
This weekend I will take the time to retest this distribution in both 32-bit and 64-bit Strawberry and pay close attention to what happens.
As Mithaldu pointed out, both David Solimano and I are smoke testing on Strawberry Perl. Also, David and I are using the 64-bit version of Strawberry whereas Gabor is using 32-bit. I couldn't tell from the RT ticket what Alexandr is using. I don't know if 64-bit versus 32-bit makes a difference.
@Mithaldu, you are probably correct. It's highly probable that a process was hung and I killed it so the build and test could continue. However, I don't remember specifically if that happened for this distribution. I haven't been taking very detailed notes regarding what has been failing.
Easily 90% of the hangs I experience are due to processes that look like this:
C:\strawberry\perl\bin\perl.exe -e "$SIG{HUP}=sub{exit}; if( my $fn=shift ){ open my $fh, qq{>$fn}; print {$fh} $$; close $fh;} my $buf; while (sysread(STDIN, $buf, 2048)) { syswrite(STDOUT, $buf); syswrite(STDERR, $buf)}" C:\Users\smoker\AppData\Local\Temp\2\qdJ32OEk0b
I think this process is created by Capture::Tiny. I always have two of them and killing one will usually let things continue. Killing both will always let things continue. The output in the shell is often showing that dmake has finished and exited with error code 0.
I will, however, occasionally kill a hanging test and let the rest of the tests continue.
That is exactly Capture::Tiny, but i couldn't imagine why it hangs. I've never observed it doing that. (In case you're curious, that program does multiplexing of STDOUT/ERR to multiple sources, so tee works on windows as well.)
Neither ActivePerl nor Strawberry Perl implement fork even remotely correctly or reliable. The only thing that works somewhat reliable is fork+exec.
In addition, Strawberry Perl has enourmous problems because some of its modules are linked against incompatible libcs, which thwarts the already very bad fork emulation code even more, and makes it hit and run, depending on what is loaded and what is not. (Strawberry Perl doesn't seem to be maintained very much anymore, as these bugs are not being fixed for multiple years now).
My recommendation would be to not try to use fork on windows for parallel processing and, failing that, to "rely" on ActivePerl, which at least tries to work properly within the limits of it's own design.
Can you link to some of these libc reports? Maintainership of Strawberry changed in recent months and it's possible kmx is not even aware of them.