view release on metacpan or  search on metacpan

Fork.pm  view on Meta::CPAN

In general, the solution for these kind of problems is to fix the
libraries or the code that leaks those file descriptors.

Fortunately, most of these leaked descriptors do no harm, other than
sitting on some resources.

=item leaked file descriptors for fork'ed processes

Normally, L<AnyEvent::Fork> does start new processes by exec'ing them,
which closes file descriptors not marked for being inherited.

However, L<AnyEvent::Fork::Early> and L<AnyEvent::Fork::Template> offer
a way to create these processes by forking, and this leaks more file
descriptors than exec'ing them, as there is no way to mark descriptors as
"close on fork".

An example would be modules like L<EV>, L<IO::AIO> or L<Gtk2>. Both create
pipes for internal uses, and L<Gtk2> might open a connection to the X
server. L<EV> and L<IO::AIO> can deal with fork, but Gtk2 might have
trouble with a fork.

The solution is to either not load these modules before use'ing
L<AnyEvent::Fork::Early> or L<AnyEvent::Fork::Template>, or to delay
initialising them, for example, by calling C<init Gtk2> manually.

=item exiting calls object destructors

This only applies to users of L<AnyEvent::Fork:Early> and
L<AnyEvent::Fork::Template>, or when initialising code creates objects
that reference external resources.

When a process created by AnyEvent::Fork exits, it might do so by calling
exit, or simply letting perl reach the end of the program. At which point
Perl runs all destructors.

Not all destructors are fork-safe - for example, an object that represents
the connection to an X display might tell the X server to free resources,
which is inconvenient when the "real" object in the parent still needs to
use them.

This is obviously not a problem for L<AnyEvent::Fork::Early>, as you used
it as the very first thing, right?

It is a problem for L<AnyEvent::Fork::Template> though - and the solution
is to not create objects with nontrivial destructors that might have an
effect outside of Perl.

=back

=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

AnyEvent::Fork itself cannot generally be used in subprocesses. As long as
only one process ever forks new processes, sharing the template processes
is possible (you could use a pipe as a lock by writing a byte into it to
unlock, and reading the byte to lock for example)

To make concurrent calls possible after fork, you should get rid of the
template and early fork processes. AnyEvent::Fork will create a new
template process as needed.

   undef $AnyEvent::Fork::EARLY;
   undef $AnyEvent::Fork::TEMPLATE;

It doesn't matter whether you get rid of them in the parent or child after
a fork.

=head1 SEE ALSO

L<AnyEvent::Fork::Early>, to avoid executing a perl interpreter at all
(part of this distribution).

L<AnyEvent::Fork::Template>, to create a process by forking the main
program at a convenient time (part of this distribution).

L<AnyEvent::Fork::Remote>, for another way to create processes that is
mostly compatible to this module and modules building on top of it, but
works better with remote processes.

L<AnyEvent::Fork::RPC>, for simple RPC to child processes (on CPAN).

L<AnyEvent::Fork::Pool>, for simple worker process pool (on CPAN).

=head1 AUTHOR AND CONTACT INFORMATION

 Marc Lehmann <schmorp@schmorp.de>
 http://software.schmorp.de/pkg/AnyEvent-Fork

=cut

1