> From: Justin Erenkrantz [mailto:[EMAIL PROTECTED] > Sent: 05 December 2001 04:25
> 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. Actually, that depends. One option is to not specify POOL_FNEW_ALLOCATOR at all. The second option, if you know the pool is going to be shared by threads but not much, pass POOL_FNEW_ALLOCATOR|POOL_FLOCK. Now, the pool will have its own allocator (which subpools will inherit) which is protected by a mutex. This is a different mutex than the one on the parent pool, so 'fighting over' mutexes would be less likely. > 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. Indeed. Currently the allocator is hidden away behind the pools API, we could opt to expose it. > 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 Sander
