From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<9807230145.AA15470@clio.rice.edu>
Subject:	Re: Ispell and pipes
To:	salvador AT inti DOT gov DOT ar (Salvador Eduardo Tropea)
Date:	Wed, 22 Jul 1998 20:45:01 -0600 (CDT)
Cc:	eliz AT is DOT elta DOT co DOT il, djgpp-workers AT delorie DOT com
In-Reply-To:	<m0yz6Hj-000S54C@inti.gov.ar> from "Salvador Eduardo Tropea" at Jul 22, 98 06:27:59 pm

> > You need to lock the code, since program B may use lots of memory and
> > cause program A to be paged out.  When the page fault happens CWSDPMI
> > won't be sure what the DOS state is.  You know, but it doesn't ...
> 
> Ugh! that's a very bad thing. Why CWSDPMI doesn't know? 

Because I didn't plan to support every flavor of DOS trying to find
an inDOS flag; there are also some bios routines (like int13) which
are also not reentrant and can trash the disk (found out about this
one personally...).  IDE controllers especially like to write over
block 0 on the disk (partition table/boot) when you try to poke
values to the I/O ports when it's in the middle of another I/O.
IDE enables interrupts and does a busy wait on a flag in memory...
which can easily be interrupted.

> Why that's 
> different than a page fault inside the program? Is because the RMCB 
> is involved? The problem is only the transition from real mode to 
> pmode?

If a page fault happens in the "main line" of the code, you know that
the bios or dos was not interrupted.  When entered via RMCB you cannot
state for sure that the BIOS or DOS's state is.  A page fault requires
disk I/O.  If you do disk I/O when DOS or the BIOS is interrupted,
you can wipe the hard disk.  Not a guarantee, but it might happen.
The consequences of losing all the contents of the hard drive are severe,
and this happened to a few people in the CWSDPMI b2 vintage days when
they wrote interrupt handlers and didn't lock properly.

We decided this wouldn't happen any more, so I added the check.  It 
has been a pain at times, but it is described this way in the DPMI
reference.

> Is enough if I lock the routine where the RMCB transfers the control 
> to pmode and nothing more? 
> If no, why that's different than a page fault inside the application? 
> (after all we *are* back in the pmode application and DOS isn't busy 
> at all).
> 
> We need to use ALL the code and data, because when the two programs 
> are piped they can be using all the code, transfer data then B uses 
> all the code, transfers data, etc...

The RMCB should be a trigger to perform some action, but all of the
work should not happen in the RMCB or you would need to lock everything.

If you really want to communicate between two images, use a protected
mode interrupt hook and modify libc's i/o routines to do the cooperative
multitasking.  Trying to handle the real multitasking (non djgpp image
pipe) is much more complicated ...

- Raw text -