TIP: Click on subject to list as thread! ANSI
echo: cis.os9.68000.osk
to: Bob van der Poel 76510,2203 (X)
from: Kim Kempf 71161,3221
date: 1991-09-15 21:58:22
subject: #12237-#Intercepts

#: 12258 S12/OS9/68000 (OSK)
    15-Sep-91  21:58:22
Sb: #12237-#Intercepts
Fm: Kim Kempf 71161,3221
To: Bob van der Poel 76510,2203 (X)

OSK uses 3 stacks at any one time: the user stack (usp), the system stack
(ssp), and an interrupt stack.  The user and system stack are one per
process.  When an interrupt occurs, OSK moves the stack to the special irq
stack and runs from there until all the irqs return.
 
The C compiler (actually C library) is tricky enough to see that F$Rte gets
called when you return from your signal handler.  And don't call me Surely.
When you call intercept() the C library stashes your function away and calls
F$SSig (or something like that) to call it's own routine on a signal.  Your
routine is called and when it returns, the wrapper routine returns via
F$RTE.  Thus, your signal handler is wrapped by the C library's handler.
Trace the code in your signal handler (asm level) and see for yourself.
 
These days, signals in OSK are a lot more reliable than they used to be.
You can be more robust in signal handlers now.  My point is that you should
realize how the signal/intercept works and set your program up in the best
way.  longjmp() sucks any time of the month and will really do nasty things
when used to jump out of a signal handler.  signal handlers that clean up
and die work the best.  The signal facility was not really designed to be
an event dispatch routine, but if you can get it to work, hey that's OS-9
for ya...

There is 1 Reply.

SOURCE: compuserve via textfiles.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.