view release on metacpan or  search on metacpan

README  view on Meta::CPAN

        For the main program, there are multiple remedies available -
        AnyEvent::Fork::Early is one, creating a process early and not using
        "new_exec" is another, as in both cases, the first process can be
        exec'ed well before many random file descriptors are open.

        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.

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

        However, AnyEvent::Fork::Early and 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 EV, IO::AIO or Gtk2. Both create
        pipes for internal uses, and Gtk2 might open a connection to the X
        server. EV and 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
        AnyEvent::Fork::Early or AnyEvent::Fork::Template, or to delay
        initialising them, for example, by calling "init Gtk2" manually.

    exiting calls object destructors
        This only applies to users of AnyEvent::Fork:Early and
        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 AnyEvent::Fork::Early, as you
        used it as the very first thing, right?

        It is a problem for AnyEvent::Fork::Template though - and the
        solution is to not create objects with nontrivial destructors that
        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
    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.

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

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

    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.

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

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

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