From c1ef87aee531fa008156ecec2dc1fc76f16c2c16 Mon Sep 17 00:00:00 2001 From: root Date: Wed, 26 Aug 2009 17:11:42 +0000 Subject: *** empty log message *** --- ev.pod | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-) (limited to 'ev.pod') diff --git a/ev.pod b/ev.pod index 00dde2e..6e07a7e 100644 --- a/ev.pod +++ b/ev.pod @@ -2110,17 +2110,28 @@ 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) and the signal handler state -(C) 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 (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 watcher and unblock them in an C watcher. +=head3 The special problem of inheritance over execve + +Both the signal mask (C) and the signal disposition +(C) 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, so handlers will be reset to C on +C), this matters for the signal mask: many programs do not expect +many signals to be blocked. + +This means that before calling C (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 -- cgit v1.2.3