in reply to Re: Proposal how to make modules using fork more portable
in thread Proposal how to make modules using fork more portable

For the record, this is all garbage.

The perceived 'problem' with kill has nothing whatsoever to do with perl's fork emulation.

It has everything to do with signals not being able to interrupt blocking IO.

It is the same problem that means that this doesn't work:

    {
         alarm 10;
         my $in = <STDIN>;
    }

[download]

Signals won't interrupt IO. Therefore, if you send a signal to a pseudo-process (thread) that is currently blocked doing IO, it won't interrupt it until the IO completes. The limitation is with the signals, not the pseudo-fork.

And documenting a limitation of signals, as a bug with fork emulation is just dumb. Presumably, p5p will reject the attempt.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^3: Proposal how to make modules using fork more portable
by Corion (Patriarch) on Apr 01, 2011 at 19:31 UTC
[reply]
      There is a deadlock condition

      I'm sorry, but I see no mention in that post of the term "deadlock", nor anything that I recognise as pertaining to it?

      Indeed, to my reading, it confirms exactly what I said above. That if blocking IO is in progress, signals won't be seen until (and unless) the IO completes:

      The sleep() function is especially implemented to return early when we receive an emulated signal (including a fake SIGALARM from our alarm() emulation).

      But if you uncomment the accept() call, then the program will just hang forever instead (unless someone actually connects to the socket, of course).

      That signals don't interrupt IO is neither a 'deadlock', nor an issue specific to pseudo-forks. It is purely a limitation of the signals implementation.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

        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.

[reply]

In Section Meditations