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.