Date:	Fri, 15 Jan 1999 03:54:58 +0000 (GMT)
From:	George Foot <george DOT foot AT merton DOT oxford DOT ac DOT uk>
To:	djgpp AT delorie DOT com
Subject:	Re: UNchain_protected_mode_interrupt_vector?
In-Reply-To:	<369E02C7.A7206CB1@giganet.com>
Message-ID:	<Pine.OSF.4.05.9901150337310.11624-100000@sable.ox.ac.uk>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com

On Thu, 14 Jan 1999, Harold Roman wrote:

> So it seems that the "chain" function creates the wrapper.

AFAICS it is allocated in the same way as the wrapper allocated
by _go32_dpmi_allocate_iret_wrapper, so the
_go32_dpmi_free_iret_wrapper function should be able to free it
-- but I didn't check whether or not this is a good idea.

> I observed that memory is disapearing faster than a 100
> bytes at a time. I put calls to
> _go32_dpmi_remaining_virtual_memory around the "chain"
> function and I observed that some times no memory is
> consumed, other times 64KB is lost. (Perhaps this really a
> memory fragmentation problem?)

When your program, or parts of libc, call malloc (in libc) it
needs to get the memory from the DPMI server.  Even if you only
allocate 100 bytes, it will get the memory in chunks of 64K.
It will satisfy further requests from that block until it
is all used up, and then it will go back to the DPMI server and
ask for another 64K chunk.  The function you're using to measure
free memory is a DPMI function -- it doesn't know anything about
what's going on inside libc.  As far as it is concerned, there's
only an occasional allocation of 64K -- no small allocations at
all.

-- 
george DOT foot AT merton DOT oxford DOT ac DOT uk

ko cilre fi la lojban  --  http://xiron.pc.helsinki.fi/lojban/

- Raw text -