Re: [boost] [thread_pool] Dependencies between tasks

Subject: Re: [boost] [thread_pool] Dependencies between tasks
From: k-oli_at_[hidden]
Date: 2008-09-06 14:42:01

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