Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

OT: Re-use system signals or create userland ones

by talexb (Chancellor)
on Aug 15, 2005 at 12:09 UTC ( #483898=perlmeditation: print w/replies, xml ) Need Help??

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.

Alex / talexb / Toronto

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

Replies are listed 'Best First'.
Re: OT: Re-use system signals or create userland ones
by fokat (Deacon) on Aug 15, 2005 at 12:34 UTC

    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.

    Best regards

    -lem, but some call me fokat

Re: OT: Re-use system signals or create userland ones
by Old_Gray_Bear (Bishop) on Aug 15, 2005 at 12:37 UTC
    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

      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

          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

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://483898]
Approved by Old_Gray_Bear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (1)
As of 2022-01-25 21:12 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    In 2022, my preferred method to securely store passwords is:












    Results (68 votes). Check out past polls.

    Notices?