summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorroot <root>2009-12-31 06:50:16 +0000
committerroot <root>2009-12-31 06:50:16 +0000
commit79c861bdfe661c42e87b0a4ec16f2ae74a076839 (patch)
tree38a7a967c8ef8d1974d9395c74097d8ee7c37c3e
parent8677f079b7fe2b47d72613d15a71d7b27f14c5eb (diff)
*** empty log message ***
-rw-r--r--Changes7
-rw-r--r--ev.c11
-rw-r--r--ev.h3
-rw-r--r--ev.pod30
4 files changed, 33 insertions, 18 deletions
diff --git a/Changes b/Changes
index 1509b84..fccc123 100644
--- a/Changes
+++ b/Changes
@@ -1,6 +1,10 @@
Revision history for libev, a high-performance and full-featured event loop.
-TODO: somehow unblock procmask?
+ - signalfd is no longer used by default and has to be requested
+ explicitly - this means that easy to catch bugs become hard to
+ catch race conditions, but the users have spoken.
+ - point out the unspecified signal mask in the documentation, and
+ that this is a race condition regardless of EV_SIGNALFD.
- backport inotify code to C89.
- inotify file descriptors could leak into child processes.
- ev_stat watchers could keep an errornous extra ref on the loop,
@@ -10,7 +14,6 @@ TODO: somehow unblock procmask?
symbols to make it easier for apps to do their own fd management.
- support EV_IDLE_ENABLE being disabled in ev++.h
(patch by Didier Spezia).
- - point out the unspecified signal mask in the documentation.
- take advantage of inotify_init1, if available, to set cloexec/nonblock
on fd creation, to avoid races.
- the signal handling pipe wasn't always initialised under windows
diff --git a/ev.c b/ev.c
index aa38d1d..ccd202b 100644
--- a/ev.c
+++ b/ev.c
@@ -1607,7 +1607,7 @@ loop_init (EV_P_ unsigned int flags)
fs_fd = flags & EVFLAG_NOINOTIFY ? -1 : -2;
#endif
#if EV_USE_SIGNALFD
- sigfd = flags & EVFLAG_NOSIGFD ? -1 : -2;
+ sigfd = flags & EVFLAG_SIGNALFD ? -2 : -1;
#endif
if (!(flags & 0x0000ffffU))
@@ -2792,11 +2792,14 @@ ev_signal_stop (EV_P_ ev_signal *w)
#if EV_USE_SIGNALFD
if (sigfd >= 0)
{
- sigprocmask (SIG_UNBLOCK, &sigfd_set, 0);//D
+ sigset_t ss;
+
+ sigemptyset (&ss);
+ sigaddset (&ss, w->signum);
sigdelset (&sigfd_set, w->signum);
+
signalfd (sigfd, &sigfd_set, 0);
- sigprocmask (SIG_BLOCK, &sigfd_set, 0);//D
- /*TODO: maybe unblock signal? */
+ sigprocmask (SIG_UNBLOCK, &ss, 0);
}
else
#endif
diff --git a/ev.h b/ev.h
index e6af59a..8e67692 100644
--- a/ev.h
+++ b/ev.h
@@ -406,7 +406,8 @@ union ev_any_watcher
#define EVFLAG_FORKCHECK 0x02000000U /* check for a fork in each iteration */
/* debugging/feature disable */
#define EVFLAG_NOINOTIFY 0x00100000U /* do not attempt to use inotify */
-#define EVFLAG_NOSIGFD 0x00200000U /* do not attempt to use signalfd */
+#define EVFLAG_NOSIGFD 0 /* compatibility to pre-3.9 */
+#define EVFLAG_SIGNALFD 0x00200000U /* attempt to use signalfd */
/* method bits to be ored together */
#define EVBACKEND_SELECT 0x00000001U /* about anywhere */
#define EVBACKEND_POLL 0x00000002U /* !win */
diff --git a/ev.pod b/ev.pod
index 9d01430..ea09df2 100644
--- a/ev.pod
+++ b/ev.pod
@@ -372,13 +372,16 @@ I<inotify> API for it's C<ev_stat> watchers. Apart from debugging and
testing, this flag can be useful to conserve inotify file descriptors, as
otherwise each loop using C<ev_stat> watchers consumes one inotify handle.
-=item C<EVFLAG_NOSIGFD>
+=item C<EVFLAG_SIGNALFD>
-When this flag is specified, then libev will not attempt to use the
-I<signalfd> API for it's C<ev_signal> (and C<ev_child>) watchers. This is
-probably only useful to work around any bugs in libev. Consequently, this
-flag might go away once the signalfd functionality is considered stable,
-so it's useful mostly in environment variables and not in program code.
+When this flag is specified, then libev will attempt to use the
+I<signalfd> API for it's C<ev_signal> (and C<ev_child>) watchers. This API
+delivers signals synchronously, which makes is both faster and might make
+it possible to get the queued signal data.
+
+Signalfd will not be used by default as this changes your signal mask, and
+there are a lot of shoddy libraries and programs (glib's threadpool for
+example) that can't properly initialise their signal masks.
=item C<EVBACKEND_SELECT> (value 1, portable select backend)
@@ -2134,7 +2137,7 @@ 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
+=head3 The special problem of inheritance over fork/execve/pthread_create
Both the signal mask (C<sigprocmask>) and the signal disposition
(C<sigaction>) are unspecified after starting a signal watcher (and after
@@ -2154,10 +2157,15 @@ The simplest way to ensure that the signal mask is reset in the child is
to install a fork handler with C<pthread_atfork> that resets it. That will
catch fork calls done by libraries (such as the libc) as well.
-In current versions of libev, you can also ensure that the signal mask is
-not blocking any signals (except temporarily, so thread users watch out)
-by specifying the C<EVFLAG_NOSIGFD> when creating the event loop. This
-is not guaranteed for future versions, however.
+In current versions of libev, the signal will not be blocked indefinitely
+unless you use the C<signalfd> API (C<EV_SIGNALFD>). While this reduces
+the window of opportunity for problems, it will not go away, as libev
+I<has> to modify the signal mask, at least temporarily.
+
+So I can't stress this enough I<if you do not reset your signal mask
+when you expect it to be empty, you have a race condition in your
+program>. This is not a libev-specific thing, this is true for most event
+libraries.
=head3 Watcher-Specific Functions and Data Members