ev signal watchers

Todd Fisher todd.fisher at gmail.com
Tue Mar 3 14:23:02 CET 2009

  I'm using libev in a queuing process.  The idea of the system is to
monitor the activity of many processes, running for long periods of time.
 The process queuing is initialized from a by inserting a record in a
database and then sending a UDP packet to the queue service.  The queue
service listens for the UDP packets and also times out to check for new work
in the database.  The thinking here, is to allow longer quiet times we can
use a network packet to wake up before the normal idle time period, but that
under high load situations missing packets is acceptable.

For the queuing system it is also important to utilize as much concurrency
on the system as possible, to do this it can be configured to create as many
worker processes as needed.  Each worker process is now setup to wait for
signals from a parent process.  If the parent is idle or receives a UDP work
packet, it will schedule work to one of it's workers, sending the worker a

The workers are setup to use ev_signal.  When a work signal is received the
worker then queues the work and notifies one of it's threads.  This thread
then determines what work is available in the database, and based on a
dynamic module begins processing.

The parent process monitors it's child workers using ev_child watchers.

The troble I'm having is the child processes stop receiving signals, from
the parent process - when there is a lot of activity.  I am able to resume
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

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

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)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.schmorp.de/pipermail/libev/attachments/20090303/dfbe21f9/attachment.html>

More information about the libev mailing list