Re: [boost] Updated version of futures library

From: Anthony Williams (anthony.ajw_at_[hidden])
Date: 2008-05-30 09:35:32

"vicente.botet" <vicente.botet_at_[hidden]> writes:

> From: "Anthony Williams" <anthony.ajw_at_[hidden]>
>> I've updated my futures library to include wait_for_any() and
>> wait_for_all().

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

That is correct.

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

I think that it can be implemented most efficiently with access to the
internals of the futures. However, it is possible to implement a
packaged_task on top of a promise.

> Should a separated packaged_task library be accepted in boost with an 
> implementation using the internals of another library?

I think that packaged_task is an important class from the user
perspective, as it simplifies task launching, which is one of the
common use cases I expect from a futures library. I therefore think it
should be provided, whatever underlying implementation we use.

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

That is the intention. The scheduler can decide which thread to run
the task on, and when, without having to know the details of the task
or how it connects to its futures. The set_wait_callback feature
allows the scheduler to know when a thread blocks on the future
associated with a task, and therefore to be able to reschedule the
task associated with that future if appropriate.

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

If there is something that cannot be done without access to the
internals, then it might mean that there is an abstraction missing. My
intent is to provide a minimal set of features that allow higher level
abstractions to be built. This is why I keep evolving the interface,
e.g. to add wait_for_any.

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

The friend declarations mean that these classes are closely related
and need to access each other's internals. This is safe because they
are provided together as a coherent whole.

I do not agree with the idea of having a public backdoor.

Anthony
-- 
Anthony Williams            | Just Software Solutions Ltd
Custom Software Development | http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL