in reply to Proposal how to make modules using fork more portable

Thanks for your feedback, corion and sundialsvc4!

This is a updated proposal of changes.

Changes to pod/perlfunc.pod

Added at end of fork

On some platforms such as Windows, where the fork() system call is not
+ available,
Perl can be built to emulate fork() in the Perl interpreter. The emula
+tion is designed to,
at the level of the Perl program, be as compatible as possible with th
+e "Unix" fork().
However it has limitation that has to be considered in code intended t
+o be portable.
See L<perlfork> for more details.

[download]

Added at end of kill

On some platforms such as Windows where the fork() system call is not 
+available.
Perl can be built to emulate fork() at the interpreter level.
This emulation has limitation related to kill that has to be considere
+d,
for code running on Windows and in code intended to be portable.
See L<perlfork> for more details.

[download]

Changes to pod/perlfork.pod

perlfork

Added at the end of =item kill()

The process which implements the pseudo-processes can be blocked and t
+he Perl interpreter
hangs.

[download]

New section added before =head1 BUGS

=head1 PORTABLE PERL CODE

In portable Perl code, kill(9, $child) must not be used on forked proc
+esses.

Forked process are in Windows implemented as a pseudo-processes. 
To use kill(9, $child) on pseudo-processes is unsafe.
The process which implements the pseudo-processes can be blocked and t
+he Perl interpreter hangs.

The outcome of kill on a pseudo-process is unpredictable.
It depends on the timing in the Windows operating system.
Code that has worked, suddenly can fail, resulting in errors which are
+ difficult to find.

[download]

Replies are listed 'Best First'.
Re^2: Proposal how to make modules using fork more portable
by BrowserUk (Patriarch) on Apr 01, 2011 at 19:26 UTC

    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.
[reply]
[d/l]
[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]
Re^2: Proposal how to make modules using fork more portable
by locked_user sundialsvc4 (Abbot) on Apr 01, 2011 at 17:33 UTC

    The last sentence can be omitted.   Just saying that there is a potential race-condition in the Windows implementation is enough.

    The statement concerning pseudo-processes “can be blocked,” etc., still feels odd to me, but it could “ship” as-is.

      Just saying that there is a potential race-condition in the Windows implementation is enough.

      There is no "race condition". Throwing out random cool phrases at problems of which you have no fundamental understanding helps no one.

      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]
Re^2: Proposal how to make modules using fork more portable
by BrowserUk (Patriarch) on Apr 01, 2011 at 18:38 UTC

    For the record, this is all garbage.

    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]

In Section Meditations