SIGHUP and Program Flow in a 6.2 Application

[Martin McCormick]

	This actually turned out to be a red herring. One of the
things I had to trace was an attempted read from /dev/ttyd0 in
which I was trying to go past the actual read. This appears to
be what thoroughly confused the trace.

	There was a logic error in the signal handler which
caused it to never exit and that was what prevented further
signals. It took me a while to figure all that out but it makes
sense.

	In my tinkering with embedded systems and
assembly-language programming, one often-times shuts off the
interrupts first thing during an interrupt handler because
disaster results if another interrupt comes in while one is
setting up the jump vector, etc. The signal handler hides all
those details, but it still has to take care of them.

	Anyway, when I fixed the logic of the handler, itself
and did not try to trace it, it does work as one would expect.

	I appreciate the help as it made me think and re-examine
what was happening. The man page more or less explains it if you
know what to look for but it wasn't close enough to what was
happening here to really help much.

Derek Ragona writes:
>Nothing needs to be in your handler function to continue running simply 
>return from your function.  However, depending on the signal you may wish 
>to call the original signal handler.  Signals like interrupts are chained 
>linked lists of handlers.  You can choose to break the chain, and have only 
>your handler called, or keep the chain intact calling the other handlers.

In this case, the chain appears to resume on return from the
routine I called on SIGHUP.