On Saturday 17 August 2013 13:35:57 Klaim - Joël Lamotte wrote:

Future/promise, packaged_task, async and c++xy extensions would then be moved in Boost.Async ?

We haven't discussed Boost.Async, just Boost.Sync for now. It seems possible, although I wonder what will be left in Boost.Thread then? Basic thread management?

...

We haven't discussed Boost.Async, just Boost.Sync for now. It seems possible, although I wonder what will be left in Boost.Thread then? Basic thread management?

Sorry that was a typo, I meant Boost.Sync yes. It's true that Boost.Thread would host only boost::thread and interruptions then, so the split I was wondering about might not really helpful, nevermind. I was just wondering because future/promise/async are, to me, synchronization mechanisms, but high-level compared to the ones you already want to separate, so I would have expected to find them with other "synchronization" mechanisms, OR in a high-level synchronization mechanism library. Future/promise/aysnc are all packed into <future> in the standard library by the way, not sure if it's the best grouping but it's notable data.

i'd rather have boost.sync provide only low-level threading classes. especially it should not depend on boost.thread to avoid cyclic dependencies. we already have the awkward situation that sync will depend on atomic, which will depend on spinlocks defined in sync ...

On Sat, Aug 17, 2013 at 2:47 PM, Andrey Semashev wrote:

We don't plan to extract futures and related stuff, it's too coupled with Boost.Thread. The main goal of Boost.Sync is to provide lightweight building blocks for low level thread synchronization and futures are beyond that.

Ok!

On Saturday 17 August 2013 17:58:52 Oliver Kowalke wrote:

2013/8/17 Andrey Semashev

...

We don't plan to extract futures and related stuff, it's too coupled with Boost.Thread. The main goal of Boost.Sync is to provide lightweight building blocks for low level thread synchronization and futures are beyond that.

futures usually depend only on mutex and condition_variable - at least it is possible to implement it this way. I would vote to decouple boost.future from boost.thread (so it could be used from other execution primitives than threads).

You can use future and promise to pass asynchronous values, true. But still, its primary use is with threads. Things like async() and future.then() use threads to carry out actions. Even if you don't use these features, you can still use futures from Boost.Thread. Note that I'm not saying there's no point in loosening this dependency of futures on threads. I'm saying that Boost.Sync doesn't look like a proper place for futures.

On Saturday 17 August 2013 20:48:49 Oliver Kowalke wrote:

2013/8/17 Andrey Semashev

...

You can use future and promise to pass asynchronous values, true. But still, its primary use is with threads. Things like async() and future.then() use threads to carry out actions. Even if you don't use these features, you can still use futures from Boost.Thread.

I mean using fibers instead threads

You can't safely use regular mutexes and condition variables with fibers, can you? If you block, you won't switch to another fiber, which you may be waiting for.

...

Note that I'm not saying there's no point in loosening this dependency of futures on threads. I'm saying that Boost.Sync doesn't look like a proper place for futures.

maybe boost.future?

Maybe. That's along the lines of the Boost.Async suggestion.

On Sat, Aug 17, 2013 at 8:39 PM, Andrey Semashev wrote:

Things like async() and future.then() use threads to carry out actions. Even if you don't use these features, you can still use futures from Boost.Thread.

That being said, I have custom code that works like async and future but take a scheduler callable (like the coming implementation) and I use work queues (associated with a thread or an update task pushed in a task scheduler) instead of threads or fiber. I'm not sure to understand how future and async really requires thread itself. to me it's only building synchronization structures between two potentially concurrent systems, whatever the way concurrency is achieved. At some point there is threads running, but it still look independant technically. Joel Lamotte

2013/8/18 Vicente J. Botet Escriba

I think we can provide a minimal future abstraction that can be used with other execution contexts, but it would need to have as parameter the associated mutex and condition_variable abstraction, otherwise I don't see how we can do it.

That's exactly what I've had in mind. namespace boost { namespace futures { template< typename R, typename Mtx, typename Cnd > class future; }} boost.thread: template< typename R > typedef futures::future< R, mutex, condition_variable > future; // uses threads thread, mutex and condition_vairable ,... are defined in the 'boost' namespace (which is an exception to other boost-libs). boost.fiber: namespace boost { namespace fibers { template< typename R > typedef futures::future< R, mutex, condition_variable > future; // uses fibers }}

Le 19/08/13 13:53, Bjorn Reese a écrit :

On 08/18/2013 11:31 PM, Vicente J. Botet Escriba wrote:

...

I think we can provide a minimal future abstraction that can be used with other execution contexts, but it would need to have as parameter the associated mutex and condition_variable abstraction, otherwise I don't see how we can do it. Maybe you have found how. If yes, I will be interested in knowing how?

It the most extreme case where no synchronization is needed, we have Boost.Expected (once it is finalized.)

Your are almost right. There are some differences between boost::expected and a future not synchronized. In particular: * future is default constructible, while expected would ensure the non-empty guaranty as boost::variant does, that is expected provides an immediate value, while future provides, well, a future value. * futures pairwise with promises, while expected is a stand alone class, * futures are movables-only, while expected can be copy_constructible, * ... Best, Vicente