Date: Mon, 20 Oct 1997 15:08:01 +0200 (IST) From: Eli Zaretskii To: Charles Sandmann cc: djgpp-workers AT delorie DOT com Subject: Re: sbrk() algorithm change suggestion In-Reply-To: <9710200547.AA12963@clio.rice.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk 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?