good chemistry is complicated, and a little bit messy -LW |
|
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
Well, this takes me back to the debate between polling and interrupt driven I/O. If it's a socket, semaphore or pipe, I have to poll it (I believe), whereas with a signal, I get interrupted. I haven't described my system in great detail, but essentially it's a web application with two daemons taking care of 'processing and moving stuff around' by checking the database, doing stuff (if necessary), then sleeping for 10-15 seconds. I'd like to be able to prod the two daemons to produce reports on what their queue situation is (from the web application), and then display the results on a web page. With a signal, the daemons will do the report right away, while using a socket will cause the daemons to do the report the next time they go through their loop. And if my use of SIGUSR1 and SIGUSR2 provokes a collision with other services, I may have to go to a socket after all .. it's just not my preferred solution. Alex / talexb / Toronto "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds In reply to Re^3: OT: Re-use system signals or create userland ones
by talexb
|
|