Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Futures for C++11 at Facebook

code.facebook.com

Post reply on HN
Print view View original

51–60 of 84 posts

Re: Futures for C++11 at Facebook

#51

Post by fugalh »

damart wrote: post #36

Futures/promises seem like they're basically just a limited subset of FRP (Rx, RAC) observables/streams - such that they either "next" once and "complete", or "error" without "nexting". I suppose they also have caching built in, but that is easy to build on top of FRP.

Indeed, any good intro to Rx points this out: Observable is the plural of future/promise.

When people are trying to do fancy streaming stuff with futures and come to me for help, I generally recommend they do the streaming with Rx instead. (eg rxcpp from Microsoft)

Re: Futures for C++11 at Facebook

#52

Post by iambvk »

Am I the only one who thinks ".then(...)" code is also unreadable? Composability with ".then(...)" looks like a workaround for C++ limitations.

Why can't we have this instead:

  fooAsync(input) {
    //...
    USING_B_THREAD_POOL
    //...
    USING_A_THREAD_POOL
    //...
    USING_B_THREAD_POOL
    //...
  }
What are the disadvantages?

Re: Futures for C++11 at Facebook

#53

Post by jasonzemos »

iambvk wrote: post #52

Am I the only one who thinks ".then(...)" code is also unreadable? Composability with ".then(...)" looks like a workaround for C++ limitations. Why can't we have this instead: fooAsync(input) { //... USING_B_THREAD_POOL //... USING_A_THREAD_POOL //... USING_B_THREAD_POOL //... } What are the disadvantages?

.then() is a hack as much as the entire async paradigm is a hack to make up for the weight of OS-supported threads used in their intended way. We have to step back and ask: what is the ideal mode of development? What does one want to do but can't? The ideal answer is to continue developing in the traditional, stackful, RAII-made-easy way where the operating system can provide a suitable natural API and runtime environment (i.e threads and kernel scheduling), and the programmer can state their intent as clearly and naturally as possible.

The std::future interface is good, but it has no truly suitable implementation. I'm not familiar with FB's Folly but at a glance I don't see it solving the fundamental problems with both std::future and callback-hell; .then() seems to just move callback-hell into one place rather than having it spread out -- it's still hell. std::future on the other hand is tied directly to the OS thread interface. Are you able to .wait() on say, 1,000,000 items at once? You'd either need 1,000,000 threads or you're bound by the slowest waiting entity in the current thread. It's definitely flawed.

The solution is to once again break down the execution context. Like threads did with processes, a new division is necessary in userspace based on stackful context switching (think boost::context crossed with boost::asio using the yield_context feature). Userspace contexts can "go to sleep" and "wake up" while being agnostic to the bounds of the thread-pool, and working fine on even a single thread. This model allows synchronous-looking programming while really acting in an asynchronous way -- which is what the obsoleted OS process/thread system offered.

"Async" and "callbacks" are really just a model of no-model -- it hasn't inverted the stack, it's basically eliminated it -- and I treat it as nothing more than temporary.

Re: Futures for C++11 at Facebook

#55

Post by revelation »

gohrt wrote: post #26
forrestthewoods wrote: post #17

Earlier quoted context omitted.

I fucking hate the terms future and promise so god damn much. The names are beyond stupid. They're just confusing as hell. No one can read the names and make an educated guess as to which is which it what they do. The following is my favorite interview response of all time. Q: what's a quaternion? A: I don't know... But I bet it has four parts. Genius! An honest answer followed by a wise educated guess. Now, what's a…

A promise what you get when you can't get a result immediately: a promise to deliver a result later. "Future" is nonsense terminology.

Or, you know, a promise is another name for assert.

Except of course it isn't. Oops.

Re: Futures for C++11 at Facebook

#56

Post by reagency »

lfowles wrote: post #27
millstone wrote: post #19

I've never programmed seriously with futures, and I'm a little apprehensive. For example, let's say I type the string "123". If there's a future / promise / async whatever anywhere, we risk processing the characters out of order. We may not catch that in testing, because it's usually fast enough that it comes out in the right order. > It is more efficient to make service A asynchronous, meaning that while B is busy c…

> What if the first request is "set sharing permissions to private" and the second request is "upload this compromising photo?" Obviously it would be bad to process these out of order. How is this handled? Upgrade the user wetware. Have them wait until confirmation that sharing permissions are now private before beginning upload.

I would never use your system. I expect a system to behave as advertised , not debug its internal state transitions

Re: Futures for C++11 at Facebook

#57

Post by jsedgwick »

amelius wrote: post #13

But how does one elegantly stop a chain of futures from executing when one is no longer interested in the final outcome of this chain of futures?

Folly Futures support interrupts and cancellations. See https://github.com/facebook/folly/blob/master/folly/futures/...

Re: Futures for C++11 at Facebook

#59

Post by stuhood »

amelius wrote: post #13

But how does one elegantly stop a chain of futures from executing when one is no longer interested in the final outcome of this chain of futures?

com.twitter.util.Future supports raising interrupts that propagate 'backwards' through the chain (and across network boundaries.) This is used to implement cancellation, among other things.

https://github.com/twitter/util/blob/master/util-core/src/ma...

Re: Futures for C++11 at Facebook

#60

Post by TwoBit »

In game development we don't use futures or similar mechanisms. We use job systems. They are much more powerful for serious muktithreading requirements. I'm not saying futures are useless at all, but we wouldn't use them where performance matters.
Post reply on HN