Date: Mon, 29 Sep 1997 10:10:33 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Charles Sandmann <sandmann AT clio DOT rice DOT edu>
cc: k3040e4 AT c210 DOT edvz DOT uni-linz DOT ac DOT at, dj AT delorie DOT com,
        djgpp-workers AT delorie DOT com
Subject: Re: [malcolm AT manawatu DOT gen DOT nz: Fork source code.]
In-Reply-To: <9709282338.AA14364@clio.rice.edu>
Message-ID: <Pine.SUN.3.91.970929100930.1917H-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Sun, 28 Sep 1997, Charles Sandmann wrote:

> So, it's DPMI provider dependent.  

Do we have any means to detect whether the DPMI host is IOPL 0 or
IOPL 3?  If not, based on what you say, it seems that CLI/STI is a
better choice, since most of the DPMI are IOPL 3.

> It is important to remember that IRET does *NOT* restore the interrupt
> flag in all enviroments, which makes interrupt/exception handling a mess.
> This is a bigger issue than the 0x900/sti stuff.

I'm sorry, I fail to understand how does this affect the
implementation of `fork' that gave birth to this thread.  I don't
recall seeing any IRETs in Malcolm's code, it just uses signals.
(Malcolm has invented a new signal that is generated by the timer
interrupt handler in itimer.c when a certain flag is set.  The handler
for that signal is the scheduler that reshuffles the threads.)

So any problems with IRET should be affecting us in any code that
involves signals, no?