2015-09-05 0:53 GMT+02:00 Giovanni Piero Deretta
So, I do not want a non-allocating future, as I think it is actually counter-productive. I only want a way to combine boost::thread::future and boost::fiber::future (i.e. in a call to wait_all/wait_any). There are two ways to do that:
1) either a simple protocol that allows efficient future interoperation (note that efficient is key here, otherwise 'then' could also work) between distinct futures.
hmmm ...
or
2) boost::fiber::future is simply a tiny wrapper over boost::thread::future that overrides the wait policy.
the futures of boost.thread and boost.fiber differ efectivly only in the type of mutex and condition_variable (implementing the suspend/resume mechanism for threads/fibers) a base implementation of future has to take the types of mutex and condition_variable as template arg. template< typename T, typename Mutex, typename Condition > class base_future<> { }; template< typename T > using future = base_future< T, boost::mutex, boost::condition_variable >; // boost.thread template< typename T > using future = base_future< T, boost::fibers::mutex, boost::fibers::condition_variable >; // boost.fiber
Shouldn't the next fiber selection be just simple list pop front when there are runnable fibers (i.e. no work stealing is required)?
yes
So boost.fiber is about an order of magnitude. It is good, but was hoping for more.
std::thread was tested
Btw, why spinlock is in details? It could be useful to expose it.
It is an implementation detail and Niall has mentioned its boost.spinlock library (1-2 years ago) and probably I could replace my spinlock implementation by a official one in the future.