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] -----------------------------------------------------------------------------
