On Tue, Dec 04, 2001 at 10:12:20PM -0500, Cliff Woolley wrote: > > > This is my second go at the pools code. > > A potential snag with the thread-specific pools idea was brought up today > when I was talking with FirstBill and some of the others. What is this > going to do to us a little ways down the road when we try to implement > async I/O, and all of the sudden requests are jumping from one thread to > another? Sounds like a big problem if thread-specific pools are in > place... is there an easy answer?
My guess would be not to pass POOL_FNEW_ALLOCATOR to apr_pool_create. It's an option passed when we create the pool, so if you can't guarantee the thread-locality of the pool, it would make sense not to split the pool off from its parent. But, the problem you are describing isn't really a concern to the pools - it's the use of the pools. All this does is allow threads in the same process to allocate memory at the same time (the current design has a bottleneck where all threads share a common per-process alloc mutex). If you control the usage of the pools so that a specific pool is only "owned" by one thread at a time, then you should be fine even with a per-thread allocator. I'd really appreciate some explanation on what this async I/O is and how it fits into the grand scheme of things. There are lots of assumptions within httpd about things being linear. -- justin
