Reactors, Channels, and Event Streams for Composable Distributed Programming

Abstract: The actor model has been a model of choice for building reliable distributed systems. On one hand, it ensures that message-processing is serialized within each actor, preserving the familiar sequential programming model. On the other hand, programs written in the actor model are location-transparent. The model is sufficiently low-level to express arbitrary message protocols. Composing these protocols is the key to high-level abstractions. Unfortunately, it is difficult to reuse or compose message protocols with actors. Reactors, proposed in this paper, simplify protocol composition with first-class typed channels and event streams. We compare reactors and the actor model on concrete programs. We identify obstacles for composition in the classic actor model, and show how to overcome them. We then show how to build reusable, composable distributed computing components in the new model.


LFE Cowboy Examples

LFE ports of the Cowboy examples.

Example Description
chunked-hello-world demonstrate chunked data transfer with two one-second delays
compress-response send a response body compressed if the client supports it
cookie set cookies from server and client side
echo-get parse and echo a GET query string
echo-post parse and echo a POST parameter
error-hook provide custom error pages
eventsource eventsource emitter and consumer
hello-world simplest example application
markdown-middleware static file handler with markdown preprocessor
rest-hello-world return the data type that matches the request type (html, json or text)
rest-basic-auth basic HTTP authorization with REST
rest-pastebin create text objects and return the data type that matches the request type (html, text)
rest-stream-response stream results from a data store
ssl-hello-world simplest SSL application
static-world static file handler
web-server serve files and list directory entries
websocket websocket example
upload multipart/form-data upload

How Erlang does scheduling

In this, I describe why Erlang is different from most other language runtimes. I also describe why it often forgoes throughput for lower latency.

TL;DR – Erlang is different from most other language runtimes in that it targets different values. This describes why it often seem to perform worse if you have few processes, but well if you have many.

From time to time the question of Erlang scheduling gets asked by different people. While this is an abridged version of the real thing, it can act as a way to describe how Erlang operates its processes. Do note that I am taking Erlang R15 as the base point here. If you are a reader from the future, things might have changed quite a lot—though it is usually fair to assume things only got better, in Erlang and other systems.

Toward the operating system, Erlang usually has a thread per core you have in the machine. Each of these threads runs what is known as a scheduler. This is to make sure all cores of the machine can potentially do work for the Erlang system. The cores may be bound to schedulers, through the +sbt flag, which means the schedulers will not “jump around” between cores. It only works on modern operating systems, so OSX can’t do it, naturally. It means that the Erlang system knows about processor layout and associated affinities which is important due to caches, migration times and so on. Often the +sbt flag can speed up your system. And at times by quite a lot…

Études for Erlang

“In this book, you will find descriptions of programs that you can compose (write) in Erlang.The programs will usually be short, and each one has been designed to provide practice material for a particular Erlang programming concept. These programs have not been designed to be of considerable difficulty, though they may ask you to stretch a bit beyond the immediate material and examples that you find in the book Introducing Erlang…”

Finding leaked processes in Erlang

lists:sort(fun({_, X}, {_, Y}) -> X > Y end,
fun(Pid, Dict) ->
InitialCall = case erlang:process_info(Pid, initial_call) of
{initial_call,{proc_lib,init_p,A}} ->
case erlang:process_info(Pid, dictionary) of
{dictionary, D} -> proplists:get_value('$initial_call', D, undefined);
_ -> {proc_lib,init_p,A}
{initial_call,{erlang,apply,A}} ->
case erlang:process_info(Pid, current_function) of
{current_function,MFA} -> MFA;
_ -> {erlang,apply,A}
{initial_call,IC} ->
Other ->
dict:update_counter(InitialCall, 1, Dict)
end, dict:new(), erlang:processes()))).

Getting started with OTP: creating psycho families

“OTP or Open Telecommunications Platform is what makes Erlang — “Erlang” (there are a lot of other thing too but I just wanted to sound dramatic !). It is such an integral part of Erlang that whenever people talk or write about Erlang they usually use Erlang/OTP. So you might be wondering what is this OTP thing. OTP is nothing but a framework for creating servers and process hierarchies. Just like you have web frameworks like django, ruby on rails for creating websites, Erlang has OTP framework for creating servers and process trees. This post will describe what process trees are, why is this OTP thing so cool and also describe why OTP creates psycho families…”