From: James Talbut (James.Talbut_at_[hidden])
Date: 2008-05-09 08:21:50
> > When a job is submitted and the pool is busy it 'may' create a new
> > thread, depending on a private algorithm.
> > You use SetThreadpoolCallbackRunsLong to influence this.
> > Bearing in mind that thread creation is expensive
> (potentially much more
> > so than simply completing a callback) you don't want to use a naiive
> > implementation that always creates new threads (unless you know your
> > jobs are big, which a library can't know).
> What the user will do if there is no more idle threads if the
> thread pool do not create it implicitly? May be resize the pool?
No, the user has no access to the actual size of the pool.
Jobs are simply queued until there is an available thread to service
New thread creation is based on the length of the queue and whether
callbacks are expected to run for a long time.
> Yes, this is not a bad idea, the user could request this
> creation explicitly with one specific parameter.
> cached_thread thread_factory::make(Callable& fct);
> cached_thread thread_factory::make(Callable& fct, force_creation_t&);
The closest you have is SetThreadpoolCallbackRunsLong.
> Yes, you are right when writing a library on top of the boost thread
> library. The question should not have the same answer if it
> the thread
> library will includes this thread factory. Do you think that
> it would be
> interesting to use this native thread pool in this case?
Oh it would probably be interesting :)
The problem is that, if you intend to support pthreads and Windows, you
need to write an abstraction layer over the Windows threadpool that also
suites the threadpool that you have to write/obtain for pthreads - and I
don't think that would be very easy (though I haven't tried writing a
thread-safe resizable threadpool using pthreads).
This e-mail, and any attachment, is confidential. If you have received it in error, do not use or disclose the information in any way, notify me immediately, and please delete it from your system.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk