From: drupp AT cs DOT washington DOT edu (Douglas Rupp)
Message-Id: <199603111850.KAA24774@june.cs.washington.edu>
Subject: Re: Itimer/Signal handler bug?
To: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Date: Mon, 11 Mar 1996 10:50:32 -0800 (PST)
Cc: drupp AT cs DOT washington DOT edu, djgpp-v2 AT delorie DOT com
In-Reply-To: <9603111807.AA13864@clio.rice.edu> from "Charles Sandmann" at Mar 11, 96 12:07:05 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

> 
> Another tidbit - when I printed out the characters from "getchar" they were
> the first two from the message sent out via printf, so it's definitely a
> transfer buffer contention issue.
> 

I recompiled the threads library w/o the time slicing option and things started
to work better. I probably should have done this to begin with, instead of
using the configuration as is.

In order to get the more sophisticated scheduling to work, signal handling
and itimers need to be made reentrant (according to some comments in the
threads code, they're not) as well as having some "safe" I/O routines.
There is, reportedly, an undocumented DOS call that will save and restore
state there, I have it in another threads package but haven;t tested it.