OT: Re-use system signals or create userland ones

[talexb]

I posed this briefly in the ChatterBox then realized it's probably more than just a Yes/No question.

My SysAdmin suggested we add a signal handler or two to a pair of daemons that we run as schedulers for our web application. These handlers would catch a signal from the web application and produce a report on "What's happening" suitable for display on a web page. We're thinking we'd like to have one suitable for public viewing, and a messier one for internal viewing. (I've already thought of clever features such as the scheduler invalidating the reports as soon as it does something that would affect the report, and not generating the report if nothing has changed since the last report was generated.)

Having had a quick look at /usr/include/asm/signal.h, I could grab two of SIGUSR1, SIGUSR2 and SIGPOLL .. or I could make up two of my own signals somewhere else (above SIGRTMAX?)

Having written a few interrupt service request handlers in my time I have a good idea about what's going on .. I'd just like some guidance on which signals might be good ones to use.

[fokat]

Hi talexb

I would simply go with the SIGUSR1 and SIGUSR2 signals, as they're already there, and this is the kind of usage for which they are meant.

[Old_Gray_Bear]

If you only need two signals, stick with USR1 and USR2; that is what they were designed for, after all. Picking any other (defined) signal will confuse either the User or the Maintainer on down the line, unless you are very clear in the documentation of your non-standard use of signal 'Foo'.

I'd really stay away from 'make up two of my own...' It's almost a non-bet that if you have someone else in the shop who 'needs' to define their own signal, above SIGRTMAX, they will pick a number you are already using. Sorting out a collision-bug like that is always fun....

[rir]

Re: stay away from 'make up two of my own...'

Please educate me.

If everyone should use SIGUSR1 and SIGUSR2, how are collisions with other people's usages ameliorated? It seems to me that collisions are more likely if people follow this advice.

I would only use SIGUSR1 or 2 since doc's suggest that behavior may be undefined if a signal is not one of "the available signals".

But I would not use signals. I view signals as the system's semaphores. A suitable use for SIGUSR might be to advertise that multiprocessing is coming or going.

I suggest sockets, unix-domain sockets, semaphores,or pipes as more suitable mechanisms to be considered.

Be well,
rir

[talexb]

I suggest sockets, unix-domain sockets, semaphores,or pipes as more suitable mechanisms to be considered.

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.