Gah - I didn't link to the top level post but to some middle mail. The top level mail describes the situation as follows:
Currently it is rather difficult to cleanly terminate a Perl program using fork() emulation on Windows:
The Perl process will only terminate once the main thread *and* all forked children have terminated.
So if the child process might be waiting in a blocked system call, we may end up with a deadlock.
The standard "solution" is to use kill(9, $child), as this is the only mechanism that will terminate a blocked thread.
However, using kill(9, $pid) may destabilize the process itself if the child process is not blocked, but actively doing something, like allocating memory from the shared heap.
So, if a pseudo-fork thread is doing some kind of system call (not only IO, but likely, as IO just takes relatively long) we get a deadlock, as the parent process needs to wait for the child thread to exit, but the child thread will never exit as it is in some blocking call.
Actually, I thought there were more problems with kill -9</c> other than "no cleanup", in the sense that the kill could create another deadlock. But upon rereading the mail, I concur with you that the lockup is mostly caused by the implementation of signals on Windows in connection with the implementation of forks.
In reply to Re^5: Proposal how to make modules using fork more portable
by Corion
in thread Proposal how to make modules using fork more portable
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |