apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henry Jen <henry...@ztune.net>
Subject Re: Thread pool prototype
Date Mon, 01 May 2006 22:53:33 GMT
William A. Rowe, Jr. wrote:
> Henry Jen wrote:

>> In a way they work the same. But there are a few interesting differences:
>> 1. Set the unused max does not force the thread to stop, an unused 
>> thread kills itself when it becomes idle and realize there are enough 
>> idle threads. Thus no joining or any locking issue for using this 
>> function.
> Is it reasonable to do a quick reap when max() is adjusted?  E.g. if the
> freecount > max then call reap?

Reasonable. Might not be optimal, but makes more sense. I feel it's kind 
of like async and sync debate.

>> 2. stop_unused_threads kills *all* unused threads regardless the 
>> unused_max.
> That's interesting - what purpose would this 'feature' serve?
>> Is that mechanism make sense or just adding complexity? Not sure. It 
>> is for occasions you want to kill all unused threads and allow them to 
>> grow later. But why does an app do that? Under a resource constraint 
>> environment, this can serve as a mechanism for error recovery. Of 
>> course, you can do that with two consequent call to set_unused_max.
> Once you've hit the wall, bits like this stand no chance of fixing things.
> Apache HTTP and APR have longstanding policies of simply bailing once
> allocations have started to fail altogether.

This sounds familiar to me. I was debating whether an app should abort 
when failed to allocate memory. I want to abort the app but others think 
it is more desirable to allow the app deal with it and trying to keep 
the app alive. :-)

Admitted it is not guaranteed, but some times it may keep the system 
alive. Assume the app is not using thread pool to manage all threads, 
and imagine there are 15 unused threads, and the app needs a turn around 
buffer of 3. By stopping all of them may last the system a little bit 

It's like you moving furnitures around to make a space in a packed room. :-)

Anyway, this is a corner case and it can still be worked around with two 
consequent calls if we stop threads when adjust the unused_max. I also 
think typically an app will set the number at beginning and forget about it.

So, let's get rid of this function and depends on unused_max_set to 
stopping idle threads.

>> Think of that, I forgot to signal the idle threads when new tasks are 
>> added! :-P
> Whoops!  :)
> What would you think in general about changing 'unused' threads to 'free'
> threads throughout the comments/implementation?

I was thinking either idle or free? Is free the general convention in apr?


View raw message