Re: [boost] [threadpool] version 22 with default pool

Subject: Re: [boost] [threadpool] version 22 with default pool
From: k-oli_at_[hidden]
Date: 2009-03-08 15:10:36

Am Sunday 08 March 2009 18:38:05 schrieb Edouard A.:
> > Am Sunday 08 March 2009 15:29:05 schrieb Edouard A.:
> > > Unfortunately, I am unable to compile the tp library. TT
> >
> > Hmm - did you try version 23? I've no problems to compile default_pool(
> > gcc-4.3).
>
> [Edouard A.]
>
> Yes, this is version 23, I am using Visual Studio 2008.

I'll test it with ms-vc soon

> > pool accepts multiple integer arguments (poolsize, high_watermark
> > low_watermark,...) - with specific types for each argument the meaning
> > of
> > each arg becomes clear (see scott meyers advise).
>
> [Edouard A.]
>
> When I initialize a std::vector, I'm happy to be able to write
> std::vector<> v(10) and not std::vector<> v(vector_size(10)). Sometimes
> parameter's purpose is obvious. Your call.

in your example vector has only one argument - tp::poll has more:
tp::pool(poolsize high_watermark, low_watermark,...)
and this is more intuitive than
tp::pool( int, int, int, ...)

> > > When scheduling several tasks with submit, I find it odd that I don't
> >
> > have
> >
> > > a  pool.wait()
> >
> > pool::shutdown() or pool::shutdown_now() -> diff. explained in the docs
>
> [Edouard A.]
>
> I'm afraid that the method name might be a bit misleading, I would expect a
> shutdown() method to kill my pool and make it unusable for later use
> without going calling startup() function.

I don't think it is missleading because it does what is names - it shuts down 
the pool. pool::shutdown() wait for all tasks and pool::shutdown_now 
intrrupts all running tasks
It makes no sense to introduce a wait() member-function because you have to 
wait in the future associated with the task ( memebr function shared_future< 
R > pool::result() ) - please look into the future documentation (link is 
inside the threadpool docu).

> I guess your internal scheduler knows when all tasks are processed, why not
> offering a condition variable... Otherwise it means I have to scan all the
> tasks to know if they are all finished. But you pointed out shutdown() and
> I think it will do the trick.
no this is complete wrong - you can wait for multiple tasks without the nned 
to shutdown the pool!
callwait_for_all() or wait_for_any() from the future lib (from Anthony 
Williams) for the tasks you are waiting for (you have to pass the 
shared_future from each task).

Oliver