view release on metacpan or  search on metacpan

Changes  view on Meta::CPAN

1.2  Wed Sep 25 13:05:09 CEST 2013
	- ->fork would not clone, but erase the arguments in the parent
          (analyzed by Christopher Paulicka).
	- mention AnyEvent::Fork::Remote, and how to be compatible to it
          in the description of the run method.
        - AnyEvent::Fork now sets a child watcher for direct children.
        - clarify that one might need to set a child watcher.
        - explicitly call exit on eof in children, to hide(!) win32 perl
          bugs. at least the test suite doesn't complain anymore, but
          the bug is doubtlessly still there.

1.1  Sun Apr 28 15:47:38 CEST 2013
	- (hopefully) remove dependency on common::sense in child code.
        - make dependency on IO::FDPass dynamic in child code.
        - actually open "communications socket" for reading AND writing
          in the child (this does not normally bother syswrite).
	- allow perl path overriding in new_exec.

1.0  Sun Apr 21 14:05:33 CEST 2013
	- implement new_from_fh and to_fh, for easy passing of

Fork.pm  view on Meta::CPAN

=head1 PORTABILITY NOTES

Native win32 perls are somewhat supported (AnyEvent::Fork::Early is a nop,
and ::Template is not going to work), and it cost a lot of blood and sweat
to make it so, mostly due to the bloody broken perl that nobody seems to
care about. The fork emulation is a bad joke - I have yet to see something
useful that you can do with it without running into memory corruption
issues or other braindamage. Hrrrr.

Since fork is endlessly broken on win32 perls (it doesn't even remotely
work within it's documented limits) and quite obviously it's not getting
improved any time soon, the best way to proceed on windows would be to
always use C<new_exec> and thus never rely on perl's fork "emulation".

Cygwin perl is not supported at the moment due to some hilarious
shortcomings of its API - see L<IO::FDPoll> for more details. If you never
use C<send_fh> and always use C<new_exec> to create processes, it should
work though.

=head1 USING AnyEvent::Fork IN SUBPROCESSES

README  view on Meta::CPAN

        might have an effect outside of Perl.

PORTABILITY NOTES
    Native win32 perls are somewhat supported (AnyEvent::Fork::Early is a
    nop, and ::Template is not going to work), and it cost a lot of blood
    and sweat to make it so, mostly due to the bloody broken perl that
    nobody seems to care about. The fork emulation is a bad joke - I have
    yet to see something useful that you can do with it without running into
    memory corruption issues or other braindamage. Hrrrr.

    Since fork is endlessly broken on win32 perls (it doesn't even remotely
    work within it's documented limits) and quite obviously it's not getting
    improved any time soon, the best way to proceed on windows would be to
    always use "new_exec" and thus never rely on perl's fork "emulation".

    Cygwin perl is not supported at the moment due to some hilarious
    shortcomings of its API - see IO::FDPoll for more details. If you never
    use "send_fh" and always use "new_exec" to create processes, it should
    work though.

USING AnyEvent::Fork IN SUBPROCESSES