Re: [boost] [future] Early draft of wait for multiple futures interface

From: Frank Mori Hess (fmhess_at_[hidden])
Date: 2008-06-01 18:53:28

On Friday 30 May 2008 18:10, Johan Torp wrote:
> Frank Mori Hess wrote:
> > once all the input futures are ready.  I see 3 options:
> >
> > 1) The combiner is run in a future-waiting thread.
> > 2) The combiner is run in a promise-fulfilling thread.
> > 3) The combiner is run in its own thread.

> I really hope option 1 is implementable without holding any locks. Could
> explain in more detail what problems you ran into?

I've got it working locally now.  The combiner and any implicit 
type-conversions now only happen in future-waiting threads, and they are 
run without holding locks.  I haven't committed it yet though, since it 
breaks my scheduler (due to some futures not completing until a wait or a 
future::ready/has_exception query is performed).  This makes my scheduler 
stall, so I'll need to implement a reasonably efficient re-useable "wait 
for any" like future_selector to fix it.  The changes also add some 
overhead.  I haven't done any measurements, but the amount of 
locking/unlocking of mutexes has definitely increased.