[ViewVC] Diff of: cvs/libev/ev.pod

Comparing libev/ev.pod (file contents):
Revision 1.260 by root, Sun Jul 19 21:18:03 2009 UTC vs.
Revision 1.265 by root, Wed Aug 26 17:11:42 2009 UTC

 =head2 FEATURES
 Libev supports C<select>, C<poll>, the Linux-specific C<epoll>, the
 BSD-specific C<kqueue> and the Solaris-specific event port mechanisms
 for file descriptor events (C<ev_io>), the Linux C<inotify> interface
-(for C<ev_stat>), relative timers (C<ev_timer>), absolute timers
+(for C<ev_stat>), Linux eventfd/signalfd (for faster and cleaner
-with customised rescheduling (C<ev_periodic>), synchronous signals
+inter-thread wakeup (C<ev_async>)/signal handling (C<ev_signal>)) relative
-(C<ev_signal>), process status change events (C<ev_child>), and event
+timers (C<ev_timer>), absolute timers with customised rescheduling
-watchers dealing with the event loop mechanism itself (C<ev_idle>,
+(C<ev_periodic>), synchronous signals (C<ev_signal>), process status
-C<ev_embed>, C<ev_prepare> and C<ev_check> watchers) as well as
+change events (C<ev_child>), and event watchers dealing with the event
-file watchers (C<ev_stat>) and even limited support for fork events
+loop mechanism itself (C<ev_idle>, C<ev_embed>, C<ev_prepare> and
-(C<ev_fork>).
+C<ev_check> watchers) as well as file watchers (C<ev_stat>) and even
+limited support for fork events (C<ev_fork>).
 It also is quite fast (see this
 L<benchmark|http://libev.schmorp.de/bench.html> comparing it to libevent
 for example).
 When the first watcher gets started will libev actually register something
 with the kernel (thus it coexists with your own signal handlers as long as
 you don't register any with libev for the same signal).
-Both the signal mask state (C<sigprocmask>) and the signal handler state
-(C<sigaction>) are unspecified after starting a signal watcher (and after
-sotpping it again), that is, libev might or might not block the signal,
-and might or might not set or restore the installed signal handler.
 If possible and supported, libev will install its handlers with
 C<SA_RESTART> (or equivalent) behaviour enabled, so system calls should
 not be unduly interrupted. If you have a problem with system calls getting
 interrupted by signals you can block all signals in an C<ev_check> watcher
 and unblock them in an C<ev_prepare> watcher.
+=head3 The special problem of inheritance over execve
+Both the signal mask (C<sigprocmask>) and the signal disposition
+(C<sigaction>) are unspecified after starting a signal watcher (and after
+stopping it again), that is, libev might or might not block the signal,
+and might or might not set or restore the installed signal handler.
+While this does not matter for the signal disposition (libev never
+sets signals to C<SIG_IGN>, so handlers will be reset to C<SIG_DFL> on
+C<execve>), this matters for the signal mask: many programs do not expect
+many signals to be blocked.
+This means that before calling C<exec> (from the child) you should reset
+the signal mask to whatever "default" you expect (all clear is a good
+choice usually).
 =head3 Watcher-Specific Functions and Data Members
 =over 4
 =item Ocaml
 Erkki Seppala has written Ocaml bindings for libev, to be found at
 L<http://modeemi.cs.tut.fi/~flux/software/ocaml-ev/>.
+=item Lua
+Brian Maher has written a partial interface to libev
+for lua (only C<ev_io> and C<ev_timer>), to be found at
+L<http://github.com/brimworks/lua-ev>.
 =back
 =head1 MACRO MAGIC
 keeps libev from including F<config.h>, and it also defines dummy
 implementations for some libevent functions (such as logging, which is not
 supported). It will also not define any of the structs usually found in
 F<event.h> that are not directly supported by the libev core alone.
-In stanbdalone mode, libev will still try to automatically deduce the
+In standalone mode, libev will still try to automatically deduce the
 configuration, but has to be more conservative.
 =item EV_USE_MONOTONIC
 If defined to be C<1>, libev will try to detect the availability of the
 be used is the winsock select). This means that it will call
 C<_get_osfhandle> on the fd to convert it to an OS handle. Otherwise,
 it is assumed that all these functions actually work on fds, even
 on win32. Should not be defined on non-win32 platforms.
-=item EV_FD_TO_WIN32_HANDLE
+=item EV_FD_TO_WIN32_HANDLE(fd)
 If C<EV_SELECT_IS_WINSOCKET> is enabled, then libev needs a way to map
 file descriptors to socket handles. When not defining this symbol (the
 default), then libev will call C<_get_osfhandle>, which is usually
 correct. In some cases, programs use their own file descriptor management,
 in which case they can provide this function to map fds to socket handles.
+=item EV_WIN32_HANDLE_TO_FD(handle)
+If C<EV_SELECT_IS_WINSOCKET> then libev maps handles to file descriptors
+using the standard C<_open_osfhandle> function. For programs implementing
+their own fd to handle mapping, overwriting this function makes it easier
+to do so. This can be done by defining this macro to an appropriate value.
+=item EV_WIN32_CLOSE_FD(fd)
+If programs implement their own fd to handle mapping on win32, then this
+macro can be used to override the C<close> function, useful to unregister
+file descriptors again. Note that the replacement function has to close
+the underlying OS handle.
 =item EV_USE_POLL
 If defined to be C<1>, libev will compile in support for the C<poll>(2)
 backend. Otherwise it will be enabled on non-win32 platforms. It

Diff Legend

-–
+Removed lines
-+
+Added lines
-<
+Changed lines
->
+Changed lines

Comparing libev/ev.pod (file contents): Revision 1.260 by root, Sun Jul 19 21:18:03 2009 UTC vs. Revision 1.265 by root, Wed Aug 26 17:11:42 2009 UTC

Diff Legend

Comparing libev/ev.pod (file contents):
Revision 1.260 by root, Sun Jul 19 21:18:03 2009 UTC vs.
Revision 1.265 by root, Wed Aug 26 17:11:42 2009 UTC