Re: [boost] [gsoc-2013] Boost.Thread/ThreadPool project

Subject: Re: [boost] [gsoc-2013] Boost.Thread/ThreadPool project
From: Dan Lincan (dan.lincan_at_[hidden])
Date: 2013-04-25 19:01:30

Hello,

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 [1], 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.

Will do.

> * 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
> her/him?

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.

[1] https://svn.boost.org/svn/boost/trunk/boost/thread/future.hpp

Thank you,
Dan