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.