From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<10004251520.AA16835@clio.rice.edu>
Subject:	Re: The new cwsdpmi
To:	eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
Date:	Tue, 25 Apr 2000 10:20:51 -0500 (CDT)
Cc:	ams AT ludd DOT luth DOT se (Martin Str|mberg),
	djgpp-workers AT delorie DOT com (DJGPP-WORKERS)
In-Reply-To:	<Pine.SUN.3.91.1000425113248.23128O-100000@is> from "Eli Zaretskii" at Apr 25, 2000 11:33:15 AM
X-Mailer:	ELM [version 2.5 PL2]
Mime-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> Also, the "Swap disk full" message might have happened inside some
> nested job, and when that job was aborted, CWSDPMI shrunk the swap
> file due to the fact that some client(s) exited and freed their
> memory.  If that's true, you won't be able to see the real size of the
> swap file when it filled the disk.

> I'm guessing that the first 3 DJGPP programs are make.exe,
> makemake.exe, and another make.exe, while the other two are gcc.exe
> and either cpp.exe or cc1.exe.  The 17KB they take up in conventional
> RAM is the normal case (16KB of transfer buffer plus some
> client-specific data).
 
> In other words, I don't see anything strange in this MEM report,
> except that I don't understand how did you get a DOS prompt in that
> situation.

If the swap file goes completely full, CWSDPMI prints the message and exits 
(it doesn't expect this condition, already returned memory to the application 
based on the fact there was free disk when the request was made, but
something used the disk space in the meantime).  If it's nested, the
task causing the problem get's it's DPMI stuff cleaned up, but when it
returns it appears we didn't properly reenter the parent image (why?  I
don't know without a complete error log...)

I don't know how much if this is due to running out of disk/memory, old
CWSDPMI behavior and new CWSDPMI behavior.

- Raw text -