Xref: news2.mv.net comp.os.msdos.djgpp:6057
From: Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: How do I use sbrk() ?
Date: Tue, 16 Jul 1996 12:04:21 CDT
Organization: Rice University, Houston, Texas
Lines: 53
Message-ID: <31ebcb95.sandmann@clio.rice.edu>
References: <960715172709_74617 DOT 365_EHH131-1 AT CompuServe DOT COM>
Reply-To: sandmann AT clio DOT rice DOT edu
NNTP-Posting-Host: clio.rice.edu
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

>      1.  What kind of memory alignment can I expect from sbrk() if any?

None.  You usually get the byte at the end of the previous allocation you
made (always in the case of unixy sbrk).

>      2. Can I expect the memory areas allocated by sbrk() to be consecutive
> or not?  

Yes, if you use unixy sbrk.  Maybe (but don't expect it) if using standard
sbrk().

>      3.  I have noticed that there is a crt0 flag that can select a unixy sbrk()
> algorythm.  What does that mean, and how is that different from the default
> algorythm?  Would that affect in any way the use of sbrk()?

Does not effect the use.  Does change the potential behavior, since sbrk()
allocations in the standard sbrk() need not be contiguous (or even strictly
increasing).

>      4.  Regarding CWSDPMI.EXE, a patch for it was discussed some time back for
> it (which I downloaded) which increases it's heap which keeps track of, among
> other things, the memory zones that a program uses.  How does this relate to the
> use of sbrk()?  

Patch isn't needed for r2, which is current.  Standard sbrk() does some pooling
of sbrk() requests (into 64K zones) but you can end up with one DPMI memory
block per zone if you sbrk() 64K.  Unixy sbrk() uses a single memory zone and
resizes it.  Resizing can result in relocation, however, and has some problems
on some DPMI providers.

> Does the DPMI providor have to keep track of every memory
> allocation of your program, thus the more one uses sbrk(), the more the DPMI
> provider has to keep track of?  

The DPMI provider must keep track of the number of DPMI memory blocks allocated.
Our current sbrk() algorithm pools requests so nothing less than 64K is 
requested from DPMI to keep the overhead down a bit.

> Thus should I minimize the number of calls to sbrk() in a program?  

The fewer the better, but it's not an absolute requirement.

> And why would the DPMI provider have to keep track of
> every memory allocation?

Because there is an address and size associated with each allocation, and
you might ask DPMI to free that memory.

>      5.  Is there any way to return some of the memory to the DPMI provider that
> has already been allocated?  If so, how?

If you call the free memory services in DPMI, yes.  In DJGPP this is only
done at image exit.