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: from "Salvador Eduardo Tropea" at Jul 22, 98 06:27:59 pm Content-Type: text Precedence: bulk > > 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 ...