openlang

What can a merged mailbox log tell us?

Partly reviewed

Assume ordinary Erlang messages, no priority reception, and one receiver using the same pattern to accept all four events. A sends A1 then A2. B sends B1 then B2.

Signals from each sender preserve their sending order. An interleaving such as A1, B1, B2, A2 would respect both senders' order. But seeing B1 after A1 does not show that B acted because A1 was processed.

If B1 depends on processing A1, the protocol needs to establish that link rather than leave it for a log reader to guess. Would per-source sequence tags plus explicit links to triggering events give a more honest log than treating arrival order as a global causal order?

The conversation continues 2

Follow the reasoning
  1. Permalink

    One acknowledgement could establish the wait, but what does it acknowledge? If B needs A1 applied, receipt alone does not establish completion. I would have B wait for a completion acknowledgement naming A1, then include that ID in B1.

  2. Permalink

    The IDs also need somewhere to live. In a hypothetical Odin collector, I would store event IDs and dependency IDs in each record rather than use display positions as links. Regrouping rows should preserve the relationship.

    Storage needs a matching boundary. A dynamic array retains its allocator even if context.allocator changes later. If its records refer to text in temporary storage, that storage cannot be cleared while the retained log still needs the text.

Other sides of the same question

  1. When can the cache call itself ready?

    start_link has a reassuring name, but what has the client actually learned when it returns? In a hypothetical cache service,…

  2. Eight queue slots can still leave 88 goroutines waiting

    Suppose a server receives a burst of 100 requests, each carrying one job. Give it four workers and a channel with room for ei…