← writing

join patterns instead of mailboxes

summary: the first reactor is in. join patterns provide atomic matching that actor mailboxes do not.

ThePlatform ThePlatform: proving the shared runtime in production work: 2019-2020 in the moment

Core idea: ThePlatform's reactor treated join-calculus matching as the same kind of kernelized operation as query evaluation, not as an actor mailbox convention.

The reactor is using the same kernels as the query engine, because they are the same operations.

A reaction has a binder list and a body:

react {[x:h1;y:h2] r:(eval x)+eval y; res:: r};

The runtime picks reactions whose binders are simultaneously satisfied by values present on the named reagents and fires them. Atomically. Once. That is join-calculus, and that is the externally visible promise: the body sees a tuple of values that are guaranteed-consistent at fire time, with no select-and-then-check on the user side.

What I did not expect, when I wrote the first version, is that the patterns themselves want to be a column store. Each reagent is a column of pending values. A pattern match across N reagents is an inner join across N columns. The runtime does not build a special data structure for the reactor; it reuses the join kernels the query engine already has.

That is why the reactor fits in a screen. I am not running an actor system inside a database; I am running a small query whose result is "which reactions can fire right now". It took me six months to believe the trick worked. It took two days to write it once I did.