【正文】 ev_loop_destroy (loop) Destroys an event loop object (frees all memory and kernel state etc.). None of the active event watchers will be stopped in the normal sense, so . ev_is_active might still return true. It is your responsibility to either stop all watchers cleanly yourself before calling this function, or cope with the fact afterwards (which is usually the easiest thing, you can just ignore the watchers and/or free () them for example).Note that certain global state, such as signal state (and installed signal handlers), will not be freed by this function, and related watchers (such as signal and child watchers) would need to be stopped manually.This function is normally used on loop objects allocated by ev_loop_new, but it can also be used on the default loop returned by ev_default_loop, in which case it is not threadsafe.Note that it is not advisable to call this function on the default loop except in the rare occasion where you really need to free its resources. If you need dynamically allocated loops it is better to use ev_loop_new and ev_loop_destroy.ev_loop_fork (loop) This function sets a flag that causes subsequent ev_run iterations to re。 if (!epoller) fatal (no epoll found here, maybe it hides under your chair)。 ~EVBACKEND_KQUEUE.It is definitely not remended to use this flag, use whatever ev_remended_backends () returns, or simply do not specify a backend at all.EVBACKEND_MASK Not a backend at all, but a mask to select all backend bits from a flags value, in case you want to mask out any backends from a flags value (. when modifying the LIBEV_FLAGS environment variable).If one or more of the backend flags are or39。s even documented that way) deadly for edgetriggered interfaces where you absolutely have to know whether an event occurred or not because you have to rearm the watcher.Fortunately libev seems to be able to work around these idiocies.This backend maps EV_READ and EV_WRITE in the same way as EVBACKEND_POLL.EVBACKEND_ALL Try all backends (even potentially broken ones that wouldn39。t work everywhere, so you might need to test for this. And since it is broken almost everywhere, you should only use it when you have a lot of sockets (for which it usually works), by embedding it into another event loop (. EVBACKEND_SELECT or EVBACKEND_POLL (but poll is of course also broken on OS X)) and, did I mention it, using it only for sockets.This backend maps EV_READ into an EVFILT_READ kevent with NOTE_EOF, and EV_WRITE into an EVFILT_WRITE kevent with NOTE_EOF.EVBACKEND_DEVPOLL (value 16, Solaris 8) This is not implemented yet (and might never be, unless you send me an implementation). According to reports, /dev/poll only supports sockets and is not embeddable, which would limit the usefulness of this backend immensely.EVBACKEND_PORT (value 32, Solaris 10) This uses the Solaris 10 event port mechanism. As with everything on Solaris, it39。s pletely useless). Unlike epoll, however, whose brokenness is by design, these kqueue bugs can (and eventually will) be fixed without API changes to existing programs. For this reason it39。t cause extra overhead. A fork can both result in spurious notifications as well as in libev having to destroy and recreate the epoll object, which can take considerable time and thus should be avoided.All this means that, in practice, EVBACKEND_SELECT can be as fast or faster than epoll for maybe up to a hundred file descriptors, depending on the usage. So sad.While nominally embeddable in other event loops, this feature is broken in all kernel versions tested so far.This backend maps EV_READ and EV_WRITE in the same way as EVBACKEND_POLL.EVBACKEND_KQUEUE (value 8, most BSD clones) Kqueue deserves special mention, as at the time of this writing, it was broken on all BSDs except NetBSD (usually it doesn39。t, and epoll just loves to report events for totally different file descriptors (even already closed ones, so one cannot even remove them from the set) than registered in the set (especially on SMP systems). Libev tries to counter these spurious notifications by employing an additional generation counter and paring that against the events to filter out spurious ones, recreating the set when required. Epoll also erroneously rounds down timeouts, but gives you no way to know when and by how much, so sometimes you have to busywait because epoll returns immediately despite a nonzero timeout. And last not least, it also refuses to work with some file descriptors which work perfectly fine with select (files, many character devices...).Epoll is truly the train wreck among event poll mechanisms, a frankenpoll, cobbled together in a hurry, no thought to design or interaction with others. Oh, the pain, will it ever stop...While stopping, setting and starting an I/O watcher in the same iteration will result in some caching, there is still a system call per such incident (because the same file descriptor could point to a different file description now), so its best to avoid that. Also, dup ()39。t scale too well (O(highest_fd)), but its usually the fastest backend for a low number of (lownumbered :) fds.To get good performance out of this backend you need a high amount of parallelism (most of the file descriptors should be busy). If you are writing a server, you should accept () in a loop to accept as many connections as possible during one iteration. You might also want to have a look at ev_set_io_collect_interval () to increase the amount of readiness notifications you get per iteration.This backend maps EV_READ to the readfds set and EV_WRITE to the writefds set (and to work around Microsoft Windows bugs, also onto the exceptfds set on that platform).EVBACKEND_POLL (value 2, poll backend, available everywhere except on windows) And this is your standard poll(2) backend. It39。s also required by POSIX in a threaded program, as libev calls sigprocmask, whose behaviour is officially unspecified.