Date: Fri, 8 Apr 1994 7:35:46 -0400 (EDT)
From: "Chris Mr. Tangerine Man Tate" <FIXER AT FAXCSL DOT DCRT DOT NIH DOT GOV>
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: Threads

Chang-Li Chin wrote:
>
>> > > 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....  
>
> 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.

First question:  the aetsk102.zip thread library only supports cooperative
threads?

Now:  just because DOS isn't reentrant doesn't mean that, for example, GO32
couldn't support any preemptive threads.  The easiest workaround is to
forbid preemptive threads from interacting with DOS; this is less of a
restriction than it sounds.  The disk-access issue might be addressable
by building a disk scheduler into GO32, and adding a layer of asynchronous
GO32-specific I/O calls.  Or, more simply, let any thread that blocks on
I/O simply yield until the I/O completes.  GO32 would have to keep track
of blocked threads, of course, but this is basic OS stuff.  Now, deadlock
detection and recovery is another story....  :-)

(I wrote deadlock detection into my kernel back in my OS-design course
in school.  Woof.)

-- chris tate
   fixer AT faxcsl DOT dcrt DOT nih DOT gov