Am Samstag, 6. September 2008 15:02:28 schrieb vicente.botet:
Well, in order to chain a task a need to have a reference to the task. This is what I meant by store a task.
ok
OK, this allows us to chain tasks. Is this function thread_safe?
yes
This works well as soon as we have a reference to the task t1 when we submit the task t2, and t2 when we submit the task t3.
you need at least one task becuase you have to tell the pool after which action/task completion the new one should be executed/chained to. Without how should the pool know to which task you refering to.
The storage of the last_task submited to the pool for a given instance is needed when the code is not linear but cyclic and the problem appears when these tasks have different types. Suppose that the function called return different types, std::string and std::size.
no - the retunr type doesn't matter.
The first function is matched by void. As chained_submit do not use at all the value stored on the future of the task, a void task coul be enough also, but we need a means to copy tp::task<T> on a tp::task<void>.
I think that the future library allows already something like that, i.e. a future<void> can be used to wait for a future<T>. Do you think that this void specialization for task<void> can be added to your library?
I would not do this because a task referes to a specific action submitted to the pool (remeber task interruption etc.). I suggest tot use the future instead.
Another idea, why not define the chained_submit with a future instead of a task as parameter?
Because submit functions from the pool return a task object thatswhy task objects are used as parameters. But you can use the future<T>::add_calback() function too. Oliver