Very Computer

Hi!
My colleague uses SIGALRM handler to do such things as reading
commands from sockets and IPC queues, controlling hardware, etc...
But I feel that it is error-prone and even not readable.  Is there any
paper or article (or even your own considerations) arguing why it is
not the best practice.
Thanks in advance,
                Eugene

--

Quote:>Hi!
>My colleague uses SIGALRM handler to do such things as reading
>commands from sockets and IPC queues, controlling hardware, etc...
>But I feel that it is error-prone and even not readable.  Is there any
>paper or article (or even your own considerations) arguing why it is
>not the best practice.

Well, at the extreme position, all one should be allowed to do is
set a variable of type sig_atomic_t (usually an int).

However, in practice, you can usually do function calls as long as what
you're calling is reentrant. So, e.g., using i/o calls, especially stdio,
is right out (you could be calling printf while you're in an interrupted
printf).

My own practice is to just set a flag (of type sig_atomic_t) and then
return. The program checks for the flag in its main loop and then safely
handles the signal at that point.

Obviously, there are exceptions to this: e.g., a handler for SIGSEGV,
which would have to diagnose and possibly remedy the problem before
returning (I believe this is how memory de*s, like ElectricFence
by Bruce Perens, work).

Another issue to consider is using longjmp to get out of a signal handler.
I don't know much about this, but I suspect that it's not terribly portable
at best, and even if it works, it's probably so confusing to the reader of
the program that it should be avoided anyway.

In summary, I agree with your view and possibly am even more conservative
about signal handling than you are. Your colleague is playing with fire,
IMHO, and when (s)he gets burned, is going to have one hell of a time
tracking down what happened.

--

PGP public key at http://www.veryComputer.com/~wozzle/alane.pgp.key

On 13 May 2000 16:08:19 +0400, Eugene Morozov

It's safe to call async-safe functions from within a signal handler.
The POSIX standard specifies a list of functions that are required
to be async safe.

Using signals can be error prone; nowadays it is better to use threads.

Even in a single threaded program, I'd rather key timer-based actions
to a timeout in a central event processing loop.

Quote:

>Another issue to consider is using longjmp to get out of a signal handler.
>I don't know much about this, but I suspect that it's not terribly portable
>at best, and even if it works, it's probably so confusing to the reader of
>the program that it should be avoided anyway.

I've never had any portability problems with longjmp when using it this
way. It is a glorified 'goto', and not being a big fan of 'goto's, my
usage of it is not great, but there are times when it makes the code
less confusing than alternatives.

--
Andrew Gabriel
Consultant Software Engineer

I think that this statement misses the point of signals: receiving a signal
means that some event or exceptional condition occurred.  Using threads,
you still have to deal with ugly run-time issues like floating point
underflow, overflow or division by zero, invalid address access, or the
arrival of an asynchronous event like "shutdown", "loss of power" or something.

All attempts to replace signals with a less general mechanism are doomed
to failure, in my opinion.  Unless you go to something at least as general
and powerful as Mach's "exception port" idea, you're going to get a lot
of half-baked, errorprone hacks.
--
Once, galactic empires might have seemed a Post-Human domain.
Now, sadly, even interplanetary ones are.

Using longjmp doesn't reset the signal mask to what it was before you
entered the signal handler. Most of the systems I've worked on have
added the current signal to the process's signal mask to prevent the
signal handler from being reentered. In short, you should use siglongjmp
rather than longjmp here, or you risk never having some signals
delivered again. Also, calling siglongjmp still means that your signal
handler never returns, which implies that you should *never* jump out of
a handler unless you *KNOW* that you were interrupted while doing
something reentrant.

Chris.

In my original post I wanted to know what are the drawbacks of
implementing _significant_ part of application logic as signal
handlers. For example checking for data in message queue in SIGALRM
handler and depending on content of the received messages turn some
hardware device on or off.
Eugene

--

        The only obvious disadvantage is that the longer time
you spend in the handler, the more time signals will be locked
out.  There could be other problems unique to your system.

Speaking only for myself,

Joe Durusau

signal/longjmp/setjmp are parts of the ISO-C-Standard and therefore are
very
portable.

        Z

I would just like to point out that this includes any function that
potentiallly may allocate memory from the heap.

Several Unices lists the async-safe functions on one of the wait* man
pages.