Re^2: OT: Re-use system signals or create userland ones

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

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

Replies are listed 'Best First'.

Re^3: OT: Re-use system signals or create userland ones
by talexb (Chancellor) on Aug 16, 2005 at 15:16 UTC

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]


Think about Loose Coupling
	PerlMonks