Futures
Futures is a framework for expressing asynchronous code in C++ using the Promise/Future pattern.
Overview
Folly Futures is an async C++ framework inspired by Twitter's Futures implementation in Scala (see also Future.scala, Promise.scala, and friends), and loosely builds upon the existing but anemic Futures code found in the C++11 standard (std::future) and boost::future (especially >= 1.53.0). Although inspired by the C++11 std::future interface, it is not a drop-in replacement because some ideas don't translate well enough to maintain API compatibility.
The primary difference from std::future is that you can attach callbacks to Futures (with then()
), under the control of an executor to manage where work runs, which enables sequential and parallel composition of Futures for cleaner asynchronous code.
Brief Synopsis
#include <folly/futures/Future.h>
#include <folly/executors/ThreadedExecutor.h>
using namespace folly;
using namespace std; void foo(int x) {
// do something with x
cout << "foo(" << x << ")" << endl;
} // ...
folly::ThreadedExecutor executor;
cout << "making Promise" << endl;
Promise<int> p;
Future<int> f = p.getSemiFuture().via(&executor);
auto f2 = f.then(foo);
cout << "Future chain made" << endl; // ... now perhaps in another event callback cout << "fulfilling Promise" << endl;
p.setValue();
f2.get();
cout << "Promise fulfilled" << endl;
This would print:
making Promise
Future chain made
fulfilling Promise
foo()
Promise fulfilled
Blog Post
In addition to this document, there is a blog post on code.facebook.com (June 2015).
Brief guide
This brief guide covers the basics. For a more in-depth coverage skip to the appropriate section.
Let's begin with an example using an imaginary simplified Memcache client interface:
using std::string;
class MemcacheClient {
public:
struct GetReply {
enum class Result {
FOUND,
NOT_FOUND,
SERVER_ERROR,
}; Result result;
// The value when result is FOUND,
// The error message when result is SERVER_ERROR or CLIENT_ERROR
// undefined otherwise
string value;
}; GetReply get(string key);
};
This API is synchronous, i.e. when you call get()
you have to wait for the result. This is very simple, but unfortunately it is also very easy to write very slow code using synchronous APIs.
Now, consider this traditional asynchronous signature for the same operation:
int async_get(string key, std::function<void(GetReply)> callback);
When you call async_get()
, your asynchronous operation begins and when it finishes your callback will be called with the result. Very performant code can be written with an API like this, but for nontrivial applications the code devolves into a special kind of spaghetti code affectionately referred to as "callback hell".
The Future-based API looks like this:
SemiFuture<GetReply> future_get(string key);
A SemiFuture<GetReply>
or Future<GetReply>
is a placeholder for the GetReply
that we will eventually get. For most of the descriptive text below, Future can refer to either folly::SemiFuture
or folly::Future
as the former is a safe subset of the latter. A Future usually starts life out "unfulfilled", or incomplete, i.e.:
fut.isReady() == false
fut.value() // will throw an exception because the Future is not ready
At some point in the future, the Future
will have been fulfilled, and we can access its value.
fut.isReady() == true
GetReply& reply = fut.value();
Futures support exceptions. If the asynchronous producer fails with an exception, your Future may represent an exception instead of a value. In that case:
fut.isReady() == true
fut.value() // will rethrow the exception
Just what is exceptional depends on the API. In our example we have chosen not to raise exceptions for SERVER_ERROR
, but represent this explicitly in the GetReply
object. On the other hand, an astute Memcache veteran would notice that we left CLIENT_ERROR
out of GetReply::Result
, and perhaps a CLIENT_ERROR
would have been raised as an exception, because CLIENT_ERROR
means there's a bug in the library and this would be truly exceptional. These decisions are judgement calls by the API designer. The important thing is that exceptional conditions (including and especially spurious exceptions that nobody expects) get captured and can be handled higher up the "stack".
So far we have described a way to initiate an asynchronous operation via an API that returns a Future, and then sometime later after it is fulfilled, we get its value. This is slightly more useful than a synchronous API, but it's not yet ideal. There are two more very important pieces to the puzzle.
First, we can aggregate Futures, to define a new Future that completes after some or all of the aggregated Futures complete. Consider two examples: fetching a batch of requests and waiting for all of them, and fetching a group of requests and waiting for only one of them.
MemcacheClient mc; vector<SemiFuture<GetReply>> futs;
for (auto& key : keys) {
futs.push_back(mc.future_get(key));
}
auto all = collectAll(futs.begin(), futs.end()); vector<SemiFuture<GetReply>> futs;
for (auto& key : keys) {
futs.push_back(mc.future_get(key));
}
auto any = collectAny(futs.begin(), futs.end());
all
and any
are Futures (for the exact type and usage see the header files). They will be complete when all/one of futs are complete, respectively. (There is also collectN()
for when you need some.)
Second, we can associate a Future with an executor. An executor specifies where work will run, and we detail this more later. In summary, given an executor we can convert a SemiFuture
to a Future
with an executor, or a Future
on one executor to a Future
on another executor.
For example:
folly::ThreadedExecutor executor;
SemiFuture<GetReply> semiFut = mc.future_get("foo");
Future<GetReply> fut1 = semiFut.via(&executor);
Once an executor is attached, a Future
allows continuations to be attached and chained together monadically. An example will clarify:
SemiFuture<GetReply> semiFut = mc.future_get("foo");
Future<GetReply> fut1 = semiFut.via(&executor); Future<string> fut2 = fut1.then(
[](GetReply reply) {
if (reply.result == MemcacheClient::GetReply::Result::FOUND)
return reply.value;
throw SomeException("No value");
}); Future<Unit> fut3 = fut2
.then([](string str) {
cout << str << endl;
})
.onError([](std::exception const& e) {
cerr << e.what() << endl;
});
That example is a little contrived but the idea is that you can transform a result from one type to another, potentially in a chain, and unhandled errors propagate. Of course, the intermediate variables are optional.
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. 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, where we take a future straight from a promise, without going via the safer SemiFuture, and where we therefore have a Future
that does not carry an executor. This is in general something to avoid.
// Thread A
Promise<Unit> p;
auto f = p.getFuture(); // Thread B
f.then(x).then(y).then(z); // Thread A
p.setValue();
This is legal and technically threadsafe. However, it is important to realize that you do not know in which thread x
, y
, and/or z
will execute. Maybe they will execute in Thread A when p.setValue()
is called. Or, maybe they will execute in Thread B when f.then
is called. Or, maybe x
will execute in Thread A, but y
and/or z
will execute in Thread B. There's a race between setValue
and then
—whichever runs last will execute the callback. The only guarantee is that one of them will run the callback.
For safety, .via
should be preferred. We can chain .via
operations to give very strong control over where callbacks run:
aFuture
.then(x)
.via(e1).then(y1).then(y2)
.via(e2).then(z);
x
will execute in the context of the executor associated with aFuture
. y1
and y2
will execute in the context of e1
, and z
will execute in the context of e2
. If after z
you want to get back to the original context, you need to get there with a call to via
passing the original executor. Another way to express this is using an overload of then
that takes an Executor:
aFuture
.then(x)
.then(e1, y1, y2)
.then(e2, z);
Either way, there is no ambiguity about which executor will run y1
, y2
, or z
.
You can still have a race after via
if you break it into multiple statements, e.g. in this counterexample:
f2 = f.via(e1).then(y1).then(y2); // nothing racy here
f2.then(y3); // racy
You make me Promises, Promises
If you are wrapping an asynchronous operation, or providing an asynchronous API to users, then you will want to make Promise
s. Every Future has a corresponding Promise (except Futures that spring into existence already completed, with makeFuture()
). Promises are simple: you make one, you extract the Future, and you fulfill it with a value or an exception. Example:
Promise<int> p;
SemiFuture<int> f = p.getSemiFuture(); f.isReady() == false p.setValue(); f.isReady() == true
f.value() ==
and an exception example:
Promise<int> p;
SemiFuture<int> f = p.getSemiFuture(); f.isReady() == false p.setException(std::runtime_error("Fail")); f.isReady() == true
f.value() // throws the exception
It's good practice to use setWith which takes a function and automatically captures exceptions, e.g.
Promise<int> p;
p.setWith([]{
try {
// do stuff that may throw
return ;
} catch (MySpecialException const& e) {
// handle it
return ;
}
// Any exceptions that we didn't catch, will be caught for us
});
Futures的更多相关文章
- Python标准模块--concurrent.futures
1 模块简介 concurrent.futures模块是在Python3.2中添加的.根据Python的官方文档,concurrent.futures模块提供给开发者一个执行异步调用的高级接口.con ...
- Guava 并行 Futures实例
Future可以用来构建复杂的异步操作,方法不是返回一个值,而是一个Future对象.创建Future对象的过程(比如调用Future异步函数接口),不会阻塞当前线程操作,而且对象第一个次创建没有值, ...
- Guava - 并行编程Futures
Guava为Java并行编程Future提供了很多有用扩展,其主要接口为ListenableFuture,并借助于Futures静态扩展. 继承至Future的ListenableFuture,允许我 ...
- 在python中使用concurrent.futures实现进程池和线程池
#!/usr/bin/env python # -*- coding: utf-8 -*- import concurrent.futures import time number_list = [1 ...
- Scala 并行和并发编程-Futures 和 Promises【翻译】
官网地址 本文内容 简介 Futures 阻塞 异常 Promises 工具 最近看了<七周七语言:理解多种编程泛型>,介绍了七种语言(四种编程范型)的主要特性:基本语法,集合,并行/并发 ...
- python简单粗暴多进程之concurrent.futures
python在前面写过多线程的库threading: python3多线程趣味详解 但是今天发现一个封装得更加简单暴力的多进程库concurrent.futures: # !/usr/bin/pyth ...
- 流动python - 写port扫描仪和各种并发尝试(多线程/多进程/gevent/futures)
port扫描仪的原理非常easy.没有什么比操作更socket,能够connect它认为,port打开. import socket def scan(port): s = socket.socket ...
- 45、concurrent.futures模块与协程
concurrent.futures —Launching parallel tasks concurrent.futures模块同时提供了进程池和线程池,它是将来的使用趋势,同样我们之前学习 ...
- python concurrent.futures
python因为其全局解释器锁GIL而无法通过线程实现真正的平行计算.这个论断我们不展开,但是有个概念我们要说明,IO密集型 vs. 计算密集型. IO密集型:读取文件,读取网络套接字频繁. 计算密集 ...
- 进程池与线程池(concurrent.futures)
from concurrent.futures import ProcessPoolExecutor import os,time,random def task(n): print('%s is r ...
随机推荐
- Linux下的Maven安装与配置
关于Maven的介绍可以参考:Maven详解 这篇在原理上讲得比较详细,在安装上是windows版本的,这里补上linux下的安装和配置: 1.下载maven安装包 http://maven.apac ...
- tomcat的安装和配置
本人java开发的菜鸟工程师,这几天学习了tomcat的安装和使用,终于在今天运行成功. 一.tomcat的安装 1.tomcat下载网址:http://tomcat.apache.org/ 2.打开 ...
- day3 文件系统 内核模块 ctags
nfs网络文件系统 smb 修改配置文件 sudo vim /etc/samba/smb.conf 重启服务 /etc/init.d/samba restart 自制小的文件系统 1 ...
- php开发中一些前端知识杂总
推荐几个jqyuey插件的好地方 http://jqueryui.com/ http://www.jq22.com/ 背景: 服务端采用ci3.0框架,twig作为模板嵌套. twig模板手册: ht ...
- 2019ICPC南昌邀请赛网络赛 I. Max answer (单调栈+线段树/笛卡尔树)
题目链接 题意:求一个序列的最大的(区间最小值*区间和) 线段树做法:用单调栈求出每个数两边比它大的左右边界,然后用线段树求出每段区间的和sum.最小前缀lsum.最小后缀rsum,枚举每个数a[i] ...
- 用eclipse打包可执行的jar(含第三方jar包)
在eclipse中的解决方式如下: 在工程目录下(与src同层)建立lib目录,将第三方Jar包放到这个目录里(copy,paste即可)[如果直接引用本地的jar,一旦换电脑就呵呵了...] 右击工 ...
- ssh/scp免密码登录传输
# 本地服务器生成key(直接回车默认) ssh-keygen # 将key传输到要登录的服务器 ssh-copy-id -i /root/.ssh/id_rsa.pub root@IP地址 # 输入 ...
- NET Core 2.2
.NET Core 2.2 新增部分功能使用尝鲜 https://www.cnblogs.com/viter/p/10070248.html 前言 美国当地时间12月4日,微软2019开发者大 ...
- 《DSP using MATLAB》示例Example 8.1
终于看到第8章了,加油,继续努力! N为奇数,有极点位于实数轴上.事实上,所有极点位于Ωc=0.5为半径的圆上,而不是单位圆.
- 《DSP using MATLAB》示例Example6.18、6.19