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: API Proposal for apr_thread_pool
Date Thu, 06 Apr 2006 04:08:20 GMT
Henry Jen wrote:
> Hi,
> 
> We would like to implement thread pool capability, and think it might be 
> a good addition to apr-util or apr.

Interesting!

I don't see where your thread join occurs to reap any terminated threads,
that is, how your model handles threads that have decided they are 'done'.

> APR_DECLARE(int) apr_thread_pool_get_num_unused_threads(void);

AIUI the style apr_thread_pool_unused_threads_num_get() would be appropriate
(_num seems awkward though, I personally prefer _count, or nothing).

> /**
>  * Stop all unused threads. Ignore the maximum number of idling threads.
>  * @return The total number of threads stopped.
>  */
> APR_DECLARE(int) apr_thread_pool_stop_unused_threads(void);

I'm a little confused in your proposal between apr_thread_pool_terminate(),
apr_thread_pool_destroy(), and this function.

Can't this be reduced to

   apr_thread_pool_shutdown()  (blocks)
   apr_thread_pool_destroy()   (same as pool cleanup)

Can you elaborate?

Final observation, your model seemed a little shortsighted, in that it permits
only a single thread pool.  This is great for an app, lousy for another library
which wishes to build upon the model.  And a group of threads might be shut down
independently of a second pool.

Can you refine the proposal with an apr_threadpool_t * object which prevents
us from adding yet another evil static singleton?  Or as an alternative, bind
the threadpool as an attribute of the pool itself, identifying the thread pool
by apr_pool_t *?

Bill

Mime
View raw message