You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Jeff Trawick <tr...@bellsouth.net> on 2001/06/07 16:11:00 UTC
thread cleanups needed (?)
I was thinking of playing with a thread-specific free list of certain
commonly-allocated structures but it would seem that there is no
proper mechanism for cleaning up the free list when the APR thread
goes away. It would be very useful to be able to register a cleanup
to be run at thread termination.
It might also be useful to register a routine to be called when a new
APR thread is created.
comments?
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: thread cleanups needed (?)
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Jeff Trawick" <tr...@bellsouth.net>
Sent: Thursday, June 07, 2001 7:11 AM
> I was thinking of playing with a thread-specific free list of certain
> commonly-allocated structures but it would seem that there is no
> proper mechanism for cleaning up the free list when the APR thread
> goes away. It would be very useful to be able to register a cleanup
> to be run at thread termination.
>
> It might also be useful to register a routine to be called when a new
> APR thread is created.
>
> comments?
Yes, yes, yes! Now the tricky part. How to implement. I'm thinking
along the same lines for loading/unloading dso's, and both in tandem
(e.g. init each thread as a dso is loaded.)
Re: thread cleanups needed (?)
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Thu, Jun 07, 2001 at 07:55:50AM -0700, rbb@covalent.net 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
Re: thread cleanups needed (?)
Posted by rb...@covalent.net.
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.
Ryan
On 7 Jun 2001, Jeff Trawick wrote:
> I was thinking of playing with a thread-specific free list of certain
> commonly-allocated structures but it would seem that there is no
> proper mechanism for cleaning up the free list when the APR thread
> goes away. It would be very useful to be able to register a cleanup
> to be run at thread termination.
>
> It might also be useful to register a routine to be called when a new
> APR thread is created.
>
> comments?
>
> --
> Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
> http://www.geocities.com/SiliconValley/Park/9289/
> Born in Roswell... married an alien...
>
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------