delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1994/04/07/23:36:36

From: ccc AT sun4 DOT ee DOT ncku DOT edu DOT tw (Chang-Li Chin (Master 92))
Subject: Re: *Very* ambitious question....
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Date: Fri, 8 Apr 1994 10:13:52 +0800 (WST)

> > > How hard would it be to add lightweight threads to GO32/DJGPP?
> > 
> > Use aetsk102.zip
> 
> ooohh... nasty... this is like programming for windows as to programming
> for os/2... that is you have to write each thread to explicity yield to get
> switch tween tasks... nasty nasty nasty.....  let the OS (or dos extender)
> take care of that....  

Threads don't necessarily be preemptive.  On UNIX-like machines, we say that
'user level' threads are normally non-preemptive which requires explicit 
yielding, and 'kernel level' threads are preemptive which should be supported
by the kernel just as they are normal tasks. Refer to the Mach C-threads 
library if interested.  For some applications, it is sufficient to have non-
preemptive threads, some other applications may work better with preemptive
threads.  As a matter of fact, there still exist some applications that 
require non-preemptive threads so that the preemptive scheduler won't mess
up with the timing or synchronization of the program!

Since MS-DOS is "semi-reentrant" (using lots of un-documented aspacts, PRINT
acts like a background task), it is very difficult to support preemptive
threads in any dos extender.  This is also why window tasks (or threads...)
are non-preemptive.  I guess the key point to this is that MS-DOS disk 
access is through the BIOS routines, which are non-reentrand AND polls for
the disk to finish its access.

Is there a background interrupt-driven disk access driver for MS-DOS in 
existance?

Charles Chin
NCKU-EE ROC

- Raw text -


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