Re: [boost] [next gen futures] Lightweight monad ready for inspection

Subject: Re: [boost] [next gen futures] Lightweight monad ready for inspection
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-06-20 08:21:50

On 20 Jun 2015 at 12:44, Avi Kivity wrote:

> On 06/19/2015 08:03 PM, Niall Douglas wrote:
> > Some may remember the thread starting from
> > http://boost.2283326.n4.nabble.com/next-gen-future-promise-What-to-cal
> > l-the-monadic-return-type-td4676039.html and that I would firstly
> > prepare an optimally lightweight monad<T> for review here before
> > going on to base a next-gen lightweight future-promise on that
> > monad<T>.
> 
>    BOOST_SPINLOCK_FUTURE_MSVC_HELP future_type get_future()
>    {
>      // If no value stored yet, I need locks on from now on
>      if(!_need_locks && _storage.type==value_storage_type::storage_type::empty)
>      {
>        _need_locks=true;
>        new (&_lock) spinlock<bool>();
>      }
> 
> 
> Isn't that the common case?  Usually if you already have a value, you 
> return it with make_ready_future().  Otherwise, at the time of 
> get_future(), the promise still doesn't have a value.

This came up in the discussion a month ago with some feeling that 
this was a pointless optimisation. I disagree for the same reasons I 
outlined back then, just because you should use make_ready_future() 
doesn't mean in generic programming you always can. A very good 
example of that is in the WG21 coroutines proposal where if the 
operations are correctly ordered and if you never enter a suspend 
point, the compiler can set the promise before getting the future and 
therefore its optimiser can completely elide the promise-future 
construct entirely. I've already raised that idea with Gor as a 
non-compiler-magic way of completely eliding future-promise overheads 
in the non-suspending coroutine outcome.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/