Date:	Mon, 20 Oct 1997 15:08:01 +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:	djgpp-workers AT delorie DOT com
Subject:	Re: sbrk() algorithm change suggestion
In-Reply-To:	<9710200547.AA12963@clio.rice.edu>
Message-ID:	<Pine.SUN.3.91.971020150722.29791P-100000@is>
MIME-Version:	1.0

On Mon, 20 Oct 1997, Charles Sandmann wrote:

> What are the down sides?  Well, you might not be able to get the last 400K
> or so of memory around handle 192.  If the DPMI provider dumps them all 
> over the virtual address space so they aren't contiguous, you might waste
> more memory.  But I think these are small disadvantages for the "hands off
> larger sizing".  For memory tight machines running relatively small apps,
> there would be no disadvantage.
> 
> One other algorithm I considered was:
>   Round size = 4K*handle#

I don't feel I know enough about this to form a separate judgement,
but if those are the only disadvantages, I'm wholeheartedly for this.
When more and more machines come with 32MB to 64MB of installed memory
right out of the box, it's embarrassing to live with a default setup
where you run out of VM after 20MB or so, even if that happens for
pathological programs.  I think we have heard more than enough of such
cases during the last 2 years.

I don't have any firm feelings about either of the algorithms, but the
latter seems simpler, which might in itself be an advantage (and maybe
code-saver).

Btw, which DPMI hosts don't free memory handles for nested clients?

- Raw text -