Flow — FoundationDB ON documentation
FoundationDB<br>7.3.77
Site Map
Site
Local Development
Internal Dev Tools
Why FoundationDB<br>Transaction Manifesto
CAP Theorem
Consistency
Scalability
Technical Overview<br>Architecture
Performance
Benchmarking
Engineering
Features
Layer Concept
Anti-Features
Experimental-Features
Transaction Processing
Fault Tolerance
Flow
Simulation and Testing
FoundationDB Architecture
FDB Read and Write Path
FDB HA Write Path: How a mutation travels in FDB HA
Consistency Checker Urgent
Client Design<br>Getting Started on macOS
Getting Started on Linux
Downloads
Developer Guide
Data Modeling
Client Testing
Testing Error Handling with Buggify
Simulation and Cluster Workloads
API Tester
Using FoundationDB Clients
Transaction Tagging
Known Limitations
Transaction profiling and analyzing
API Version Upgrade Guide
Tenants
Automatic Idempotency
Design Recipes<br>Blob
Blob
Hierarchical Documents
Hierarchical Documents
Multimaps
Multimaps
Priority Queues
Priority Queues
Queues
Queues
Segmented Range Reads
Segmented Range Reads
Simple Indexes
Simple Indexes
Spatial Indexing
Spatial Indexing
Subspace Indirection
Subspace Indirection
Tables
Tables
Vector
Vector
API Reference<br>Python API
Ruby API
Java API
Go API
C API
Error Codes
Special Keys
Global Configuration
Tutorials<br>Class Scheduling
Managing Large Values and Blobs
Time-Series Data
Administration<br>Configuration
Moving a Cluster to New Machines
Transport Layer Security
Authorization
Monitored Metrics
Redwood Storage Engine
Visibility Documents<br>Request Tracing
Earlier Release Notes<br>Release Notes
Release Notes
Release Notes
Release Notes
Release Notes
Release Notes
Release Notes
Release Notes
Release Notes
Release Notes
Release Notes
Release Notes
Release Notes
Release Notes
Release Notes
Release Notes
Release Notes
Release Notes
Release Notes
Release Notes
Release Notes
Release Notes
Release Notes
Release Notes
Release Notes
Release Notes
Page
Flow<br>Engineering challenges
A first look
Flow features<br>Promise and Future
wait()
ACTOR
State
PromiseStream, FutureStream
waitNext()
choose … when
Example: A Server Interface
Caveats
" Fault Tolerance
Simulation an... "
Flow<br>Engineering challenges
A first look
Flow features<br>Promise and Future
wait()
ACTOR
State
PromiseStream, FutureStream
waitNext()
choose … when
Example: A Server Interface
Caveats
Flow
Engineering challenges
FoundationDB began with ambitious goals for both high performance per node and scalability. We knew that to achieve these goals we would face serious engineering challenges while developing the FoundationDB core. We’d need to implement efficient asynchronous communicating processes of the sort supported by Erlang or the Async library in .NET, but we’d also need the raw speed and I/O efficiency of C++. Finally, we’d need to perform extensive simulation to engineer for reliability and fault tolerance on large clusters.
To meet these challenges, we developed several new tools, the first of which is Flow, a new programming language that brings actor-based concurrency to C++11. To add this capability, Flow introduces a number of new keywords and control-flow primitives for managing concurrency. Flow is implemented as a compiler which analyzes an asynchronous function (actor) and rewrites it as an object with many different sub-functions that use callbacks to avoid blocking (see streamlinejs for a similar concept using JavaScript). The Flow compiler’s output is normal C++11 code, which is then compiled to a binary using traditional tools. Flow also provides input to our simulation tool, which conducts deterministic simulations of the entire system, including its physical interfaces and failure modes. In short, Flow allows efficient concurrency within C++ in a maintainable and extensible manner, achieving all three major engineering goals:
high performance (by compiling to native code),
actor-based concurrency (for high productivity development),
simulation support (for testing).
A first look
Actors in Flow receive asynchronous messages from each other using a data type called a future. When an actor requires a data value to continue computation, it waits for it without blocking other actors. The following simple actor performs asynchronous addition. It takes a future integer and a normal integer as an offset, waits on the future integer, and returns the sum of the value and the offset:
ACTOR Futureint> asyncAdd(Futureint> f, int offset) {<br>int value = wait( f );<br>return value + offset;
Flow features
Flow’s new keywords and control-flow primitives support the capability to pass messages asynchronously between components. Here’s a brief overview.
Promise and Future
The data types that connect asynchronous senders and receivers are Promise and Future for some C++ type T. When a sender holds a Promise, it represents a promise to deliver a value of type T at some...