Re: [boost] Updated version of futures library

From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-05-30 09:02:56

----- Original Message ----- 
From: "Anthony Williams" <anthony.ajw_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, May 30, 2008 11:54 AM
Subject: [boost] Updated version of futures library

> Hi all,
>
> I've updated my futures library to include wait_for_any() and
> wait_for_all().
>
> The provided overloads allow either waiting on up to five futures
> known at compile time:
>
> unique_future<int> f1;
> shared_future<std::string> f2;
> unique_future<double> f3;
> unsigned const ready_index=wait_for_any(future1,future2,future3);
>
> or on a container of futures:
>
> std::vector<jss::shared_future<int> > futures;
> std::vector<jss::shared_future<int> >::iterator const future=
>    jss::wait_for_any(futures.begin(),futures.end());
>
> In the first instance, they can be of distinct types, but in the
> latter, all the futures in the container must be of the same type.
>
> The documentation is available at
> http://www.justsoftwaresolutions.co.uk/files/futures_documentation.html
> and the files and tests are available at
> http://www.justsoftwaresolutions.co.uk/files/n2561_futures_revised_20080530.zip
>

Hello,

in the implementation of wait_for_any you use the  future_object_base which 
is in the detail namespace and you have added an external_waiters member to 
this class.

Does it mean that the future interface from 20080515 do not allows to 
implement this function in an efficient way?

This was also the case of packaged_task which depends on 
detail::future_object<T>. Does it mean that the future interface from 
20080515 (extracting the packaged_task specifics) do not allows to implement 
the packaged_task interface in an efficient way?
Should a separated packaged_task library be accepted in boost with an 
implementation using the internals of another library?

Does the current packaged_task interface allows to implement a task 
scheduler with features we have not determined yet, without modifying the 
internals of packaged_task, and futures?

Does all this means that in order to implement higher level abstraction on 
top of the future library we need to use the internals and/or change the 
future library implementation?

IMO this is a symthom the future library interface is not enough open, and 
than there are some internals abstractions that should be made public.

In addition you have added a lot of friends declarations, in particular 
unique_future has 4 friend classes and shared_future has 3.

        friend class shared_future<R>;
        friend class promise<R>;
        friend class packaged_task<R>;
        friend class detail::future_waiter;

When we have such a number of friend classes this means that the non public 
interface is a little bit public. In this case it will be better to identify 
these interfaces and group them in a backdoor. This allows to separate the 
interface used by applications and the one used by libraries.

Best,

Vicente