At 07:46 AM 3/6/2008, Martin McCormick wrote:
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.
Good to hear you got things working. Debugging signal handlers and
interrupt handlers is always a challenge. I am an old assembly coder too,
and have done embedded work as well. It can be very challenging in any
environment debugging these, particularly with re-entrancy issues.
-Derek
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.
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
