ev signal watchers

Marc Lehmann schmorp at schmorp.de
Wed Mar 4 13:42:48 CET 2009


On Tue, Mar 03, 2009 at 08:23:02AM -0500, Todd Fisher <todd.fisher at gmail.com> wrote:
> signal processing by putting the whole process to sleep and waking it back
> up (cntrl+z fg)...  This behavior seems odd and I'm wondering if by off
> chance anyone has

that it continues to run with ctrl-z/fg indicates thta most likely
the process hangs in a read or write (or similar) syscall, which gets
interrupted.

if you can strace the process or attach a debugger and make a backtrace
when it hangs, that would be very informative. (stracing might make it
work, though, debugger is better).

as for how to do it best, here is what happens when you use signals:

- signal delivery takes a few thousand cycles
- libev then writes into a pipe, taking another 1-2k cycles
  (less on linux with eventfd, but still...)
- libev reads from the pipe, taking a few hundred cycles

in contrast, when you use a pipe yourself, you save on the signal
delivery.

> 1. any suggestions about this queuing system design, e.g. the use of signals
> to communicate to a child process vs using a pipe?

it's simply slower, as libev uses a pipe itself already, for handling
signals, and signals are costly.

> 2. any suggestions about why the worker processes might stop receiving
> signals from their parent, unless the system goes to sleep (e.g. cntrl+z/fg)

either a bug in libev or in your program. for example, when your program
expects one signal per event, then it won't work reliably, as you will not
receive one signal callback per signal sent.

signals are, in general, relatively timely and reliable, when done right,
but they are hard to use right, and quite slow.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      pcg at goof.com
      -=====/_/_//_/\_,_/ /_/\_\



More information about the libev mailing list