From:	mcastle AT cs DOT umr DOT edu
Subject:	*Possible* method of adding signal support
To:	djgpp AT sun DOT soe DOT clarkson DOT edu
Date:	Mon, 23 Nov 92 11:34:39 CST

I've been wondering about a way to handle signal support.  

Could the same mechanism for envoking the math emulators be used for calling
code in the main program?

I seem to remember browsing through the source for go32 one time, and 
noticing some exception handling, but it seemed to be limited to handling
math errors (for calling the emulator).

Now, I assume that all math errors will happen in protected mode, so there
is some support in go32 for that.  There is also turbo_assist(), for 
transposing djgpp specific interrupts into the appropriate dos calls, so 
support also exists for go32 to handle at least some interrupts in PM. 
And of course, turbo has real-mode interrupt handling already.  

What I'm proposing is this:

Trap all dos-type signals that are similiar to unix-type signals (sigint,
sigfpe, maybe sigterm (same as sigkill?)).  When an appropriate signal is
captured, a table is looked up to see how to handle it.  If properly
written, this table should be accessible from both real- and protected-
mode (or maybe duplicated).  If the user program had request sig_dfl or
sig_ill, the appropriate action can take place.  If a requested routine
is to be exectuted, then it is called in the sameway that the math 
emulators are called (these do just do a return instead of an iret, don't
they?).

Signal() and raise() could just be turbo_assist() calls that either place
the appropriate information in a table internal to go32 or calls the 
appropriate signal handling event.  Actually, if we include raise(), more
signals could be handled.  

Potential (and possible insurmountable problems): 

o   Handling the signal while in real-mode.
A possible solution would be to just delay handling until protected mode
is re-entered.  

o   Reetrancy.
Well, signal handlers are supposed to be re-entrant anyway, arent' they?
But maybe toggling interrupts around the call would be a good idea?
Would that dis-allow turbo-assist calls then, though?  (aside: anyone ever
written a signal handler that calls raise() and do recursive signals?)



Anyway, what I'm basically trying to say is:  If some exception handling
is available for use the math emulators, couldn't that method be extended
to also handle other exceptions.

Note: I'm only suggesting signal handling here, no interrupt handling for
the user program.

Also, sorry if all this is a bit incoherent, but I've recently taken to 
working a graveyard shift to help pay for school :-<

randomly mumbling,
mrc

- Raw text -