"Oliver Kowalke" <k-oli@gmx.de> writes:
I did a look into draft n2276 - a launch_in_pool function is suggested (passing task to a system provided threadpool).
Is it reasonable to have a static threadpool?
Yes.
How many worker-threads should this pool contain and how are the submitted tasks queued (FIFO, priority order ... unlimited/limited number of tasks can bes stored).
In the proposal, that's up to the implementer to choose. The only requirement is that in the absence of coding errors, a submitted task will actually complete (i.e. the code should run as if each task was on its own thread, but possibly delayed in starting). This contrains the work-stealing algorithms in use, but allows the number of threads to be dynamic, and the order to be up to the implementation. If the pool cannot accept any more tasks (whether that's because there's a hard-coded limit, or because it runs out of memory) then the task submission should fail.
What about applications which require a pool with different configuration than the static pool provides?
Don't use the static pool. Alternatively provide overloads of launch_in_pool that allow task properties to be specified (e.g. "this thread spends lots of time doing blocking waits" => maybe schedule an extra thread).
Is it acceptable to pay for an unused pool?
It could be initialized on first use. Anthony -- Anthony Williams Author of C++ Concurrency in Action | http://www.manning.com/williams Custom Software Development | http://www.justsoftwaresolutions.co.uk Just Software Solutions Ltd, Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK