Subject: Re: [boost] [gsoc-2013] Boost.Thread/ThreadPool project
From: Dan Lincan (dan.lincan_at_[hidden])
Date: 2013-04-25 19:01:30
I have tried to answer most of the questions.
> * Why the submit function of all the thread pools doesn't returns the same?
It's omitted in 1. thead_pool for increased performance.
> * What is the advantage of returning future from submit call?
Users can wait for the function call to finish and retrieve the result.
> * Would the destructor of the future resulting of the submit call wait until
> the task has been finished?
After looking at , it wouldn't.
> * What about having a specific time based pool that will submit the function
> to another pool once the duration/time_point has elapsed/reached?
It can work but the problem is how do I know how many threads to give
to the second pool?
>Or specific free functions submit_after/submit_at that use a hidden
> thread/queue to manage with the time constraint?
Separate thread for there two functions seems like a solution. Two
priority queues could be used to store there functions/tasks.
To determine when to move the function/task to the global queue of the
threadpool some timers could be used. When new task/function is
submitted the priority queue would update and, if needed, the timer
too ( if the submitted task is the 1st to be executed ).
> * I would provide a submit function that has as parameter the function to
> call and its parameters, as std::async, std::thread::thread, or
> std::packaged_task provide, so that the user is not forced to use bind.
> * For a work-stealing thread pool the user would need a function to force
> the scheduling of new jobs when it needs to wait for some jobs to finish.
Can you explain, please?
> * From the interface all the pools are non-blocking, that is the queue are
> not bounded. Have you some thought about thread pool that have bounded
> queues and that could block or tell the user that the queues are congested,
A new function could be added so the user can check if the queue is full.
> * Quite frequent we need to submit jobs that need to be handled in a
> sequential order, what do you propose for this use case?
This is a similar case to the submit_at and submit_after functions.
Insead of time we'd introduce priority.
> * In addition to submitting a job after/at a given duration/time_point have
> been elapsed/reached, we often need to submit a job that needs the result of
> another job. How a user would be able to do it. Would the library help
Not in the form it is now.
> * It would be great to reference existing libraries/proposals and how your
> proposal solves limitations you can find in the referenced libraries.
The problem is that I cannot give solutions that solves all the
problems of multiple other libraries without performance costs.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk