#: 12220 S12/OS9/68000 (OSK)
    12-Sep-91  23:52:01
Sb: #12171-#Intercepts
Fm: Kim Kempf 71161,3221
To: Bob van der Poel 76510,2203 (X)

>Now, I'm still confused my MW's refusal to permit this technique.  After
 
[RE: longjmp from an intercept routine]
 
Things might look OK, but your stack is overflowing.  The signals are
delivered to the process on an alternate stack that is specific to the
process, but different from the stack the process is using in user mode.
You *must* call F$RTE after the intercept routine to pop the stack and
allow the next signal to be delivered.  If you are executing
in an intercept routine and another signal is delivered, it won't be
processed until the intercept completes.  If you longjmp() out of it
the F$RTE never gets called.  If you intend to clean up things and exit,
that's not too bad, but I've yet to run into a situation that couldn't
be reorganized to set a global exit flag to cause the program to exit.
 
The warnings by MW about I/O are historical because signals in the past
(before V1.3?) were not queued:  if the process was in the intercept
handler, the signal being sent was discarded.  Now they are queued and
you're obligated to process them promptly or things start to get wasted.
C language I/O (read printf()) use static memory for output buffers which
may get stomped on if they are running and a signal interrupts it.  Even
worst, malloc() has this problem (yikes!).  The safest signal handlers
(in UNIX, too) just set global flags and return.  A fully ANSI-comformant
program is restricted to this anyway.  Hope this helps.

There are 2 Replies.