Date:	Tue, 16 May 2000 17:00:06 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Tim Updegrove <tdu AT enter DOT net>
cc:	djgpp AT delorie DOT com
Subject:	Re: Algorithm for integer timing loop
In-Reply-To:	<39207b3e.1189164@news.enter.net>
Message-ID:	<Pine.SUN.3.91.1000516165428.25864C-100000@is>
MIME-Version:	1.0
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

On Mon, 15 May 2000, Tim Updegrove wrote:

> Thank-you for asking for a small test case.  In creating it, I found a
> key piece of info.  It only fails after doing a Control+C in a Windows
> 98 SE (also  Win95) and then restarting the program.  The 1st time it
> runs great but after killing it and restarting it, then it fails the
> very first time.  What is Windows doing?

Yes, it looks like if you interrupt `utime', the emulation of the timer 
for that DOS box is screwed up and will refuse to be reprogrammed.

>  Is there a fix?

A simple solution is to block SIGINT while you run that loop.  You don't 
really need to stop it with Ctrl-C, do you?  You could, for example, use 
`signal' and SIG_IGN, or `sigprocmask' for that.

It is also possible that some changes inside `uclock' will make it more 
robust in these cases (e.g., perhaps there's some command to reset the 
PIT, and if used inside `uclock', it would restore the virtualized PIT 
to its normal state).  But I didn't have enoug time to look for such a 
solution; volunteers are welcome, as usual.

- Raw text -