view release on metacpan or  search on metacpan

README  view on Meta::CPAN

        shell use, or badly-written programs), but "SIGPIPE" can cause
        spurious and rare program exits as a lot of people do not expect
        "SIGPIPE" when writing to some random socket.

        The rationale for installing a no-op handler as opposed to ignoring
        it is that this way, the handler will be restored to defaults on
        exec.

        Feel free to install your own handler, or reset it to defaults.

RECOMMENDED/OPTIONAL MODULES
    One of AnyEvent's main goals is to be 100% Pure-Perl(tm): only perl (and
    its built-in modules) are required to use it.

    That does not mean that AnyEvent won't take advantage of some additional
    modules if they are installed.

    This section explains which additional modules will be used, and how
    they affect AnyEvent's operation.

    Async::Interrupt
        This slightly arcane module is used to implement fast signal
        handling: To my knowledge, there is no way to do completely
        race-free and quick signal handling in pure perl. To ensure that
        signals still get delivered, AnyEvent will start an interval timer
        to wake up perl (and catch the signals) with some delay (default is
        10 seconds, look for $AnyEvent::MAX_SIGNAL_LATENCY).

        If this module is available, then it will be used to implement
        signal catching, which means that signals will not be delayed, and
        the event loop will not be interrupted regularly, which is more
        efficient (and good for battery life on laptops).

        This affects not just the pure-perl event loop, but also other event
        loops that have no signal handling on their own (e.g. Glib, Tk, Qt).

        Some event loops (POE, Event, Event::Lib) offer signal watchers
        natively, and either employ their own workarounds (POE) or use
        AnyEvent's workaround (using $AnyEvent::MAX_SIGNAL_LATENCY).
        Installing Async::Interrupt does nothing for those backends.

    EV  This module isn't really "optional", as it is simply one of the
        backend event loops that AnyEvent can use. However, it is simply the
        best event loop available in terms of features, speed and stability:
        It supports the AnyEvent API optimally, implements all the watcher
        types in XS, does automatic timer adjustments even when no monotonic
        clock is available, can take avdantage of advanced kernel interfaces
        such as "epoll" and "kqueue", and is the fastest backend *by far*.
        You can even embed Glib/Gtk2 in it (or vice versa, see EV::Glib and
        Glib::EV).

        If you only use backends that rely on another event loop (e.g.
        "Tk"), then this module will do nothing for you.

    Guard
        The guard module, when used, will be used to implement
        "AnyEvent::Util::guard". This speeds up guards considerably (and
        uses a lot less memory), but otherwise doesn't affect guard
        operation much. It is purely used for performance.

    JSON and JSON::XS
        One of these modules is required when you want to read or write JSON
        data via AnyEvent::Handle. JSON is also written in pure-perl, but
        can take advantage of the ultra-high-speed JSON::XS module when it
        is installed.

    Net::SSLeay
        Implementing TLS/SSL in Perl is certainly interesting, but not very
        worthwhile: If this module is installed, then AnyEvent::Handle (with
        the help of AnyEvent::TLS), gains the ability to do TLS/SSL.

    Time::HiRes
        This module is part of perl since release 5.008. It will be used
        when the chosen event library does not come with a timing source of
        its own. The pure-perl event loop (AnyEvent::Loop) will additionally
        load it to try to use a monotonic clock for timing stability.

    AnyEvent::AIO (and IO::AIO)
        The default implementation of AnyEvent::IO is to do I/O
        synchronously, stopping programs while they access the disk, which
        is fine for a lot of programs.

        Installing AnyEvent::AIO (and its IO::AIO dependency) makes it
        switch to a true asynchronous implementation, so event processing
        can continue even while waiting for disk I/O.

FORK
    Most event libraries are not fork-safe. The ones who are usually are
    because they rely on inefficient but fork-safe "select" or "poll" calls
    - higher performance APIs such as BSD's kqueue or the dreaded Linux
    epoll are usually badly thought-out hacks that are incompatible with
    fork in one way or another. Only EV is fully fork-aware and ensures that
    you continue event-processing in both parent and child (or both, if you
    know what you are doing).

    This means that, in general, you cannot fork and do event processing in
    the child if the event library was initialised before the fork (which
    usually happens when the first AnyEvent watcher is created, or the
    library is loaded).

    If you have to fork, you must either do so *before* creating your first
    watcher OR you must not use AnyEvent at all in the child OR you must do
    something completely out of the scope of AnyEvent (see below).

    The problem of doing event processing in the parent *and* the child is
    much more complicated: even for backends that *are* fork-aware or
    fork-safe, their behaviour is not usually what you want: fork clones all
    watchers, that means all timers, I/O watchers etc. are active in both
    parent and child, which is almost never what you want. Using "exec" to
    start worker children from some kind of manage prrocess is usually
    preferred, because it is much easier and cleaner, at the expense of
    having to have another binary.

    In addition to logical problems with fork, there are also implementation
    problems. For example, on POSIX systems, you cannot fork at all in Perl
    code if a thread (I am talking of pthreads here) was ever created in the
    process, and this is just the tip of the iceberg. In general, using fork
    from Perl is difficult, and attempting to use fork without an exec to
    implement some kind of parallel processing is almost certainly doomed.

    To safely fork and exec, you should use a module such as Proc::FastSpawn
    that let's you safely fork and exec new processes.

    If you want to do multiprocessing using processes, you can look at the