"vicente.botet" <vicente.botet@wanadoo.fr> writes:
From: "Anthony Williams" <anthony.ajw@gmail.com>
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....
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