could you have it so that some of the pool structure is allocated at startup
so that every thread for every process has a initialized pool ready for the request to use when the request gets torn down, the pool is re-inited at the end (after the request has finished) that way you could access it via the scoreboard structure > -----Original Message----- > From: Justin Erenkrantz [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 07, 2001 9:20 AM > To: [EMAIL PROTECTED] > Cc: Jeff Trawick; [email protected] > Subject: Re: thread cleanups needed (?) > > > On Thu, Jun 07, 2001 at 07:55:50AM -0700, [EMAIL PROTECTED] wrote: > > > > Isn't there always a pool associated with a thread? > Register the cleanup > > with that pool, and you should solve your problem. If not, then the > > thread creation routines should also be creating a > sub-pool. That would > > solve the problem. I know that was the original plan, but whether I > > implemented it that way or not, I can't remember. > > +1. > > I don't think this is implemented right now. A lot of this > has to do with > the interaction with httpd and threaded MPM. IIRC, httpd has > a worker pool > (specific to a bunch of threads), but no thread-specific pool. > > I'd love to see some type of pool that is thread specific. > I've tossed > this idea around, but never got around to it. At the same time, we > should add some hooks in the modules to allow them to have > thread-specific initialization. IMHO, child_init isn't fine-grained > enough in httpd with threaded MPM. > > My problem has always been how to access the thread-specific pool once > it is created. Especially in the httpd case, you can't always use > apr_threadkey_private (what about prefork MPM?). There needs to be a > place in the request_rec (I think) for a pool which can only > be used at > one time by one worker. -- justin >
