apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: Terminating threads in a process, WAS: RE: [PATCH] Problems with MPM threaded
Date Tue, 17 Jul 2001 23:28:37 GMT
From: "dean gaudet" <dean@arctic.org>
Sent: Tuesday, July 17, 2001 6:15 PM


> if you assume that you want some form of notification, but you want to
> leave it unspecified because you're not sure what each apr thread will be
> used for, then you can make a somewhat generic "kill off other threads"
> cleanup.
> 
> so for example, when an httpd thread is created it would register
> http_thread_cleanup which would use whatever magic global int
> die_now_please = 1, and release some condition variable, or throw
> something into a queue / and so on.
> 
> that would be registered in the "parent" thread's pool -- and would only
> be invoked by the "parent" thread.
> 
> pools let you do this, you don't need the mutexes for it, you just have to
> be explicit about parallelism.  (combine that with a root pool per thread
> and then we can remove alloc_mutex and free lists and push the real gnarly
> problems into the libc malloc where it's probably best solved.)

Yes, yes, yes.  Can we please split the concept of a heirarchial parent (the
'creator' thread's or process pool, in this case) from the allocation parent
(the actual give me memory for my pool from ... here!)  Then we have an 
"OS Knows Best" malloc/free mpm for threading, just as you suggest.

This solves your thread-specific requirements and our scoping issues, along
with fixing the 'walk the chain of pools for a block' problem, both at once.




Mime
View raw message