Hi, 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 SIGUSR1. 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) Thanks, Todd
_______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
