#: 12253 S12/OS9/68000 (OSK)
    15-Sep-91  11:17:02
Sb: #12237-#Intercepts
Fm: Robert Heller 71450,3432
To: Bob van der Poel 76510,2203 (X)

The "other stack" is probably not an A7-type stack (USP/SSP), but the signal
queue/process state info in your process's descriptor.  This is what the F$RTE
"pops".  It is not so much a stack but your process's state - in intercept vs.
not in intercept.  When your intercept routine is called, you get called with a
stack frame above your current USP (i.e. the kernel pushes stuff (its user-mode
return address, the signal number, etc) onto your stack.

A longjump will restore the USP/registers/PC to the state at the setjump, but
does nothing about your process's state info in its process descriptor.

VMS (as well as UNIX and OS9) has a simular problem with I/O in Control-C
handlers.  We have this big system (LLVS), written in a combination of C and
VAXLIsp.  A Control-C handler is provided to allow users to abort an task. The
way it work is there is a ^C handler that just sets a global flag and another
function that is called at periodic times from the main program which checks
the ^C flag.  I've found this method of handling ^C's to be the safest (and
most portable) way to go.  Almost any program has one or more major loops -
adding one line of code (check_control_c();) is usually easy.  The control c
checking function checks the global flag, and if set, does the cleanup and
exits.

                        Robert

There is 1 Reply.