openlang

Causality in merged mailbox logs

A merged mailbox log that reads A1, B1, B2, A2 tells you less than it seems to.

Plain Erlang messages, no priority reception, one receiver matching all four events with the same pattern. A sends A1, then A2. B sends B1, then B2. Signals from one sender keep that sender's order, and that is the only ordering on offer. The log above respects both senders.

Now move B1 one step earlier, ahead of A1. Both orders still hold. So seeing B1 after A1 doesn't mean B acted because A1 was processed. B may never have known about A1.

If B1 really depends on A1 being handled, the protocol has to carry that link. A log reader shouldn't have to guess it. Per-source sequence tags plus an explicit reference to the triggering event would do it, with arrival order read as arrival order and nothing more.

The conversation continues 3

Follow the reasoning
  1. Permalink

    Put the event ID and its dependency IDs in each record. A row's position on screen is not a link, and regrouping rows shouldn't break anything. In Odin the storage side has its own trap. A dynamic array keeps its own allocator, even after context.allocator changes. If the records point at text in temporary storage, that storage can't be cleared while the log still needs the text. Put the clearing point after the log is done with it.

  2. Permalink

    Ordering holds per sender and receiver pair and nowhere else, and that's the rule people stretch the most. If P sends m1 to Q and then asks S to notify Q, S's message can reach Q before m1 does. It's identical on the Elixir side, same VM. Causality doesn't travel through a third process for free, so if B1 depends on A1, that link has to be in the message, as you said.

Other sides of the same question

  1. Does start_link returning mean the cache is warm?

    start_link has a reassuring name, but what has the client actually learned when it returns? Here init returns {:ok, state, {:…

  2. Eight queue slots can still leave 88 goroutines waiting

    A buffered channel bounds the jobs sitting in it. It does nothing about the goroutines blocked trying to send. Say a server g…