X-Authentication-Warning:	delorie.com: mailnull set sender to djgpp-bounces using -f
Date:	Tue, 29 Jan 2002 13:32:10 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Florian Schulze <florian DOT proff DOT schulze AT gmx DOT net>
cc:	djgpp AT delorie DOT com
Subject:	Re: multi-threading
In-Reply-To:	<a35vdp$4rk$00$1@news.t-online.com>
Message-ID:	<Pine.SUN.3.91.1020129132506.7261C-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Tue, 29 Jan 2002, Florian Schulze wrote:

> > If this limitation is okay, you can build your scheduler as a handler for
> > some signal, like SIGALRM, and use timers to preempt threads.
> 
> This is how it's done in LWP.

Granted, I know that ;-)

> Is a signal really processed after all system calls?

In DJGPP, yes.  That is how DJGPP programs manage to convert a Ctrl-C 
keypress, even if it happens while the CPU is in the middle of a DOS 
call on behalf of your program, into a simple function call.

In DJGPP, hardware interrupts that are supposed to be translated into 
signals are caught by an interrupt handler which invalidates the DS 
selector (by setting its segment limit to 4KB, the null page).  Then they 
do an IRET.  So the invalid selector will have no effect until the 
program is back in protected mode and touches some of its data.  When it 
does, the invalid DS selector will cause a GPF.  That GPF invokes an 
exception handler installed by the startup code; the exception handler 
realizes that the GPF was triggered intentionally, restores the DS 
selector limit to its previous state, and simply calls the appropriate 
signal handler (SIGINT for Ctrl-C, SIFALRM for the timer tick, etc.).

- Raw text -