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
in thread OT: Re-use system signals or create userland ones
by talexb
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |