Re: [boost] Boost.Fiber mini-review September 4-13

Subject: Re: [boost] Boost.Fiber mini-review September 4-13
From: Oliver Kowalke (oliver.kowalke_at_[hidden])
Date: 2015-09-04 22:38:40

2015-09-05 0:53 GMT+02:00 Giovanni Piero Deretta <gpderetta_at_[hidden]>:

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