in reply to OT: Re-use system signals or create userland ones

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....

----
I Go Back to Sleep, Now.

OGB

  • Comment on Re: OT: Re-use system signals or create userland ones

Replies are listed 'Best First'.
Re^2: OT: Re-use system signals or create userland ones
by rir (Vicar) on Aug 16, 2005 at 12:41 UTC
    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

[reply]
        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.

      Alex / talexb / Toronto

      "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

[reply]
[d/l]
[select]

In Section Meditations