Date: Sun, 19 Dec 1999 16:25:28 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Gerald Hilderink <g DOT h DOT hilderink AT el DOT utwente DOT nl>
cc: djgpp AT delorie DOT com
Subject: RE: returning from interrupt with iret?
In-Reply-To: <NCBBKDJKGFDAILDODIIGGEBOCBAA.g.h.hilderink@el.utwente.nl>
Message-ID: <Pine.SUN.3.91.991219161927.177B-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Sun, 19 Dec 1999, Gerald Hilderink wrote:

> Currently the context switch is delayed until the interrupt returns. The
> problem with delaying interrupts is that somewhere a bit must be checked (by
> polling) in the code. To ensure immediate pre-emptive behaviour this must be
> checked frequently. I have learned that polling seems to be easy and
> flexible, but it is a source for complexity and error-prone.

The DJGPP signal-generation solves this dilemma by triggering an
exception.  To that end, the ISR (e.g., the keyboard handler that sees a
Ctrl-C keypress) invalidates the DS selector by setting its limit to the
first 4KB.  It also sets a special fake-exception flag, and then the ISR
returns. 

Since the DS selector is invalid, the first time the foreground program
tries to access any of its data or stack, a GPF is triggered.  The DJGPP
exception handler looks at the fake-exception flag, realizes that this
is a pending signal, and calls "raise (sig)".

That's it!  Simple and safe.  The SIGINT, SIGALRM and SIGPROF signals 
which originate from hardware interrupts are all implemented in this 
way, so all the basic machinery is already in place in every DJGPP 
program.  This is what I suggested for your case as well.