[Date Prev][Date Next]
Re: Thread-local malloc discussion summary
On Wednesday, April 9, 2003, at 04:01 PM, Howard Chu wrote:
I had hoped that search could be adapted without impacting a lot of
code, but it dragged out to more than I expected. The current
troublesome due to the need to keep global heap allocs separate from
thread-local allocs. We can allow some sloppiness here by changing the
sl_realloc and sl_free functions to simply pass through to ch_realloc
ch_free if the passed-in pointer does not reside in the thread-local
I'd like to see some profile results showing the current version's
effectiveness before pursuing this any further. Certainly it is a bit
but it's also harder to use...
Does it make sense to start separating allocations into separate
types so that they might be (eventually) implemented differently
on different platforms? Some allocations need to be global, some
can be within a thread, and many could probably benefit from stack-
allocation. Implemented using #defines for example. Environments
with a working alloca() could then use it. (with no-op for the free)
Environments without it would fall back to a malloc() or thread-
local system and still have the appropriate free() call when needed.
I think you've mentioned that getting autoconf to reliably state
whether alloca is usable is tricky. This shouldn't be a problem
as we can just enable it for specific architectures that are known
to support it.