Joe Wilson <[EMAIL PROTECTED]> wrote:
> --- [EMAIL PROTECTED] wrote:
> > Mostly I am interested in making sure that malloc(1000) does not
> > fail even though you have 50000 bytes free and they just happen
> > to be scattered about as 100 discontinguous blocks of 500 bytes
> > each.  
> 
> It's a good goal. You can reduce the likelihood of failure perhaps, 
> but I don't think that you can guarantee it without moving blocks
> and reswivelling all the pointers.

So Joe's advice is give up and go home. Duely noted. But if it 
is all the same to you, I think I will ignore this advice and
press onward...

> 
> Is this memory pooling going to be compile-time optional?
> 
> I find that library-specific memory pools are awkward because each
> library tends to have its own schemes that don't play well with each
> other. If you use pools, then that limits the effectiveness of Hoard 
> or Boehm GC in a big application.
> 

There are no current plans to make this optional, since to do
so would instantly double the number of configurations I need
to support.

We have no plans to go to mmap or sbrk for memory.  All of the
memory SQLite will manage will come from either a static array
(mem3.c) or from a few large mallocs (mem1.c and mem2.c).  I 
fail to see how this could adversely effect other libraries 
within the same program.  It just means that SQLite calls
malloc less often.

--
D. Richard Hipp <[EMAIL PROTECTED]>


-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------

Reply via email to