From ff1b7be8909060849721a42b1851099e80cd3d40 Mon Sep 17 00:00:00 2001 From: James Sedgwick Date: Wed, 21 Jan 2015 11:41:50 -0800 Subject: [PATCH] use wait()/get() instead of while(!f.isReady()) { ... } Summary: as above. nice redness. couple of comments inline though Test Plan: contbuild Reviewed By: hans@fb.com Subscribers: trunkagent, zeus-diffs@, cold-storage-diffs@, targeting-diff-backend@, apollo-diffs@, micha, folly-diffs@, jsedgwick FB internal diff: D1787776 Tasks: 5940008 Signature: t1:1787776:1421776843:13772348538a0af27ceb5a363b818ece0cdfffc6 --- folly/futures/README.md | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/folly/futures/README.md b/folly/futures/README.md index 39a1aa81..013e78c8 100644 --- a/folly/futures/README.md +++ b/folly/futures/README.md @@ -154,13 +154,7 @@ That example is a little contrived but the idea is that you can transform a resu Using `then` to add callbacks is idiomatic. It brings all the code into one place, which avoids callback hell. -Up to this point we have skirted around the matter of waiting for Futures. You may never need to wait for a Future, because your code is event-driven and all follow-up action happens in a then-block. But if want to have a batch workflow, where you initiate a batch of asynchronous operations and then wait for them all to finish at a synchronization point, then you will want to wait for a Future. - -Other future frameworks like Finagle and std::future/boost::future, give you the ability to wait directly on a Future, by calling `fut.wait()` (naturally enough). Futures have diverged from this pattern because we don't want to be in the business of dictating how your thread waits. We may work out something that we feel is sufficiently general, in the meantime adapt this spin loop to however your thread should wait: - - while (!f.isReady()) {} - -(Hint: you might want to use an event loop or a semaphore or something. You probably don't want to just spin like this.) +Up to this point we have skirted around the matter of waiting for Futures. You may never need to wait for a Future, because your code is event-driven and all follow-up action happens in a then-block. But if want to have a batch workflow, where you initiate a batch of asynchronous operations and then wait for them all to finish at a synchronization point, then you will want to wait for a Future. Futures have a blocking method called wait() that does exactly that and optionally takes a timeout. Futures are partially threadsafe. A Promise or Future can migrate between threads as long as there's a full memory barrier of some sort. `Future::then` and `Promise::setValue` (and all variants that boil down to those two calls) can be called from different threads. BUT, be warned that you might be surprised about which thread your callback executes on. Let's consider an example. -- 2.34.1