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 X-Sender: eliz AT is To: Florian Schulze cc: djgpp AT delorie DOT com Subject: Re: multi-threading In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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.).