Date: Sun, 30 Jan 2000 22:39:20 +0500 (MVT)
From: Prashant TR <prashant_tr AT yahoo DOT com>
To: Martin Stromberg <eplmst AT lu DOT erisoft DOT se>
cc: djgpp AT delorie DOT com
Subject: Re: posix threads with djgpp
In-Reply-To: <8719mn$mu5$2@antares.lu.erisoft.se>
Message-ID: <Pine.LNX.4.10.10001302232240.571-100000@yahoo.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com
Errors-To: dj-admin AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

On 30 Jan 2000, Martin Stromberg wrote:

> But I wondered what would happen if the processor was in some DOZE
> call, an interrupt comes along (I'm assuming that DOZE can be
> interrupted) which some code (not necessarily DJGPP code) handles by
> invalidating the CS selector and then returns to the DOZE call. What
> would happen now (in the DOZE call)?

The routines in any OS don't invalidate the CS. When Windows (or any
32-bit OS) is interrupted, the CS is filled from the IDT descriptor or
from the value in the TSS. At no point of time can the CS contain garbage.
If anything attempted to load garbage into CS, that would immediately
cause a GP Fault (which could crash Windows ;-)).

So, it is not possible for any program to invalidate CS. If Windows tries
to get back to the original process, the retf or iret would itself cause
GP Fault. So, there's no way any such thing can take place.