www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1998/05/19/06:17:25

Date: Tue, 19 May 1998 13:14:37 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Paul Derbyshire <pderbysh AT usa DOT net>
cc: djgpp AT delorie DOT com
Subject: Re: Threading and asynchronous processes
In-Reply-To: <co681.8622$z15.6304438@news21.bellglobal.com>
Message-ID: <Pine.SUN.3.91.980519130638.21766B-100000@is>
MIME-Version: 1.0

On Tue, 19 May 1998, Paul Derbyshire wrote:

> How does it manage this, using a timer interrupt to plant a signal whose
> handler manages task switching? What signal is used?

Either SIGALRM or SIGTIMR, I'd guess.  DJGPP already has almost all the 
facilities to generate these signals on a timer tick.  (A PM handler for 
Int 8 is installed when you call `alarm' or one of the itimer functions.)

But the signal delivery is delayed until system calls like spawn and 
others which call DOS/BIOS return.  So when a thread spawns a child 
program, all the other threads won't get CPU until the child program 
exits.

> How so... are there any other mechanisms? Which if any wouldn't bomb under
> WIndows, or Desqview, or some other non-CWSDPMI environment? Is there a way to
> at least run multiple DJGPP programs using such a scheme, or would it be easier
> to design a method of dynamically loading modules?

I'm no specialist in this field, but using other methods is surely much 
more tricky and crash-prone, since doing anything non-trivial from a 
protected-mode hardware interrupt handler is tantamount to running 
circles on a minefield.  The fact that DJGPP's signals work like they do 
is no coincidence.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019