Date:	Sun, 21 Jan 2001 15:09:34 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Tim Van Holder <tim DOT van DOT holder AT pandora DOT be>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: Interaction between __dpmi_yield and signals?
In-Reply-To:	<NEBBIOJNGMKPNOBKHCGHGENPCAAA.tim.van.holder@pandora.be>
Message-ID:	<Pine.SUN.3.91.1010121150237.16311F-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Sun, 21 Jan 2001, Tim Van Holder wrote:

> the Smalltalk testsuite has a test for its delay mechanism, which
> aborted due to a SIGALRM, even though a signal handler was properly
> installed. I tracked the problem to a function called 'relinquish',
> which uses select() to relinquish control for a short time. Using
> sleep() gave the same result, probably because both called
> __dpmi_yield(). Changing the relinquish() function to do nothing at
> all on DJGPP does work, however. I just don't see why calling
> __dpmi_yield would cause a SIGALRM not to be delivered properly.

It shouldn't.  Moreover, I think I've seen a signal interrupt 
`__dpmi_yield' many times, with no visible problems.

First, make sure the problem persists with stock v2.03 library.  If it 
does, I'd first suspect that Smalltalk's `relinquish' isn't as innocent 
as your description suggests; perhaps it does something which in the DJGPP 
case disables or interferes with the signal handling machinery.

As another data point, does a simple test program which sets up a timer 
and then calls `select' to wait forever succeeds to DTRT?

Also, make sure you do NOT run this under a debugger.  The DJGPP debug 
support doesn't work reliably when timers fire, this is a known bug for 
which there's no solution or work-around yet.  If you did run this under 
a debugger, chances are your observations have very little to do with the 
actual problems.

- Raw text -