Re: [boost] [thread_pool] Dependencies between tasks

Subject: Re: [boost] [thread_pool] Dependencies between tasks
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-09-07 08:19:07

----- Original Message ----- 
From: <k-oli_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Saturday, September 06, 2008 8:42 PM
Subject: Re: [boost] [thread_pool] Dependencies between tasks

>
> 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.

I've not said at any moment that we don't need a task reference.

>> 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.

For what the return 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 don't see the relation with task interruption, could you elaborate more on 
that? Which use case have you in mind?

> I suggest tot use the future instead.

Do you mean that it is up to the user to chain the tasks using 
future<T>::add_calback()?

>> 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.

IMHO, this is not a deep rational. If all what is needed to chain a task is 
a future why not provide this interface?
If you ADD another prototype for chained_submit taking as

boost::future<T>& f instead of a tp::task<T> & t
            template<typename Act,  typename T>
            tp::task< typename result_of< Act() >::type > chained_submit(
                 Act const& act,boost::future<T> &f )
  {
   shared_lock< shared_mutex > lk( mtx_state_);
   if ( terminated_() )
    throw task_rejected("pool ist terminated");
   if ( terminateing_() )
    throw task_rejected("pool ist terminateing");

   typedef typename result_of< Act() >::type R;
   detail::interrupter intr;
   promise< R > prom;
   channel_item itm(
    future_wrapper< R >(
     act,
     prom),
    intr);
   fut.add_callback(
    bind(
     ( channel_iterator ( channel::*)( channel_item const&) ) & 
channel::put,
     ref( channel_),
     itm) );
   return task< R >( prom, intr);
  }

The implementation of the current chained_submit will just forward the call 
passing the future of the task.
  task< typename result_of< Act() >::type > chained_submit(
   Act const& act,
   task< T > & tsk)
{ return chained_submit(act, tsk.get_future());}

> But you can use the future<T>::add_calback() function too.

I'm not sure if you mean that my use case (example) can be implemented with 
chained_submit or not? If it can be implemented, as the use case (example) 
is quite simple, please could you complete the code example to show how you 
will implement it?

Regards,

Vicente