Date:	Thu, 4 Jun 1998 20:47:49 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	Morten Welinder <terra AT diku DOT dk>, Charles Sandmann <sandmann AT clio DOT rice DOT edu>,
	DJ Delorie <dj AT delorie DOT com>
cc:	djgpp-workers AT delorie DOT com
Subject:	__dpmi_yield considered harmful (sometimes)
Message-ID:	<Pine.SUN.3.91.980604203131.2197V-100000@is>
MIME-Version:	1.0

I need your urgent help in coming up with ideas about this calamity.  
(The only reason for ``urgent'' is that I have an unlimited access to a 
machine where I can reproduce this problem for the next week; after that 
it will be much harder for me to debug this problem.)

Some of you might have read the thread about Bash hanging on Windows 95 
after the first time it runs a DJGPP program in an interactive session.  
One of the users who reported this was able to trace it to the call to 
__dpmi_yield which apparently doesn't return.

I couldn't reproduce this on the machines I usually work on.  Now I found 
a machine where this happens as well, so I'm asking you to help solving 
it, if you can take a couple of moments to reflect on this.

Here's what I know: any DJGPP program that runs another DJGPP program, and
after the child returns issues a call to __dpmi_yield, will hang on the
machines which are affected by this.  I saw the same behavior with Bash,
Emacs, Less, and the latest port of Info. 

When they hang, only Ctrl-Alt-Del can help you.  Even Ctrl-BREAK has 
no effect.  Bash is different in this last respect: Ctrl-BREAK aborts it, 
but the traceback shows DS=0 and SS that's invalid, and the DOS box is 
hung after Bash aborts anyway.  I suppose Bash is different because it 
pulls DPMI-specific tricks when running programs, to work around bugs in 
Windows.

It doesn't matter how do you run the subsidiary program: via `spawn', via 
`system', or even shell to COMMAND.COM and run it from the command line 
(the parent hangs when you type EXIT).  Non-DJGPP programs can be run 
with no visible problems.

I have no idea why some systems are afflicted by this while others (most 
of them, actually) aren't.

It seems like some snafu with nested DPMI programs, probably a bug in 
Windows 95's DPMI, but that doesn't help you if you have such a system.

So if you can think about possible reasons, or suggest things to try to 
learn more, please dump your thoughts on me.  I suppose a desperat 
solution would be to make __dpmi_yield look at a (yet another) 
environment variable and do nothing if it says so, but I would really 
like to solve this, as it is not nice to eat CPU cycles while waiting.

Thanks in advance for any help.

- Raw text -