Consistency model

[selfup]

As has been discussed in #31:

We should start planning on how to handle concurrency in the future.

File IO does not lock in the std lib, and we should evaluate which crate (or our own hand-rolling), would do the best at achieving this job.

Once we pick out how to tackle this, we then need to pick a strategy.

---

So far we have discussed:

• completely locked down
• partially locked down (this is going to be trickier) - (better for reads)
• some kind of while loop, that waits for the file to be closed, and sends a signal on open and on close
• native socket messages that give stop and go signals in order
• a different way than listed

---

Things to consider:

• safety over speed
• a solid mix
• speed is our only concern

[selfup]

So far, I would more or so favor:

• completely locked down
• Safety over speed

Up for debate!

[cite-reader]

The important thing is really the concurrent semantics we want to offer. There's an infinite family of possible models to choose from or construct, but only a handful of actually interesting ones. I'm going to push hard for linearizable semantics, which is what users generally expect.

For a treatment of concurrency models and how they break down in practice, I suggest the Jepsen posts. The problem we're solving isn't as difficult as the problems Jepsen tests for (we're single-node by design, so we don't ever have to worry about partitions) but our users are potentially concurrent, so there's some overlap. And the posts are good reading, too.

[selfup]

Thanks for further defining the problem set at hand.

I will read over the Jepsen Posts