Figure out how to support concurrent runs of elm-review without corrupting the cache

[lishaduck]

Disappointing, but I guess I just means I need to find the time to do that refactor of options parsing that'll let us quit spawning processes. (And I guess the caching issues was probably actually this too)

At some point, it'd probably also be good to do some form of file locking or something to handle concurrent modifications better, but on the other hand, I suppose we sorta do, with the --namespace option, but I don't see how we could get that set in tests.

Originally posted by @lishaduck in #322 (comment)

Yeah, the namespace option was meant for that. Though it's also a shame to need that, as that means that a cache for the CLI would not get used by an editor and vice versa. If we could get rid of it that would actually be nice I think.

@lishaduck opening an issue would be great 👍

Originally posted by @jfmengels in #322 (comment)

---

I see three four ways to go about this:

1. PR elm/compiler to fix it corrupting concurrent builds (I don't know Haskell, so I couldn't do this; otherwise, this sounds like the best plan)
2. Automatically namespacing (Doesn't allow sharing caches between concurrent runs, but would at least stop the bleed and suppress the issue 😉) [I figure I'll probably take this route when I try to fix it.]
3. Use file-locking (would probably get unduly slow and doesn't really fix the problem)
4. Use a daemon to memoize it (best perf, lots of work, probably couldn't be done in JSLand) [The Lamdera compiler is looking into this, perhaps some collaboration would be done?].

[jfmengels]

Automatically namespacing

Do you know what we'd namespace by? Because if it in practice causes a cache MISS on everything, then that's going to be terrrible for performance.

[lishaduck]

Automatically namespacing

Do you know what we'd namespace by? Because if it in practice causes a cache MISS on everything, then that's going to be terrrible for performance.

I figured we'd create a file listing current runs and lock on that instead of the full elm-stuff folder. Then, when a run is running, other runs will see that a run is progress and namespace with an index. So the first one would be [1], the second would be [2]. If you run a third while [2] is still running but [1] is done, then it can claim the [1] index.
If you did something stupid on accident like spawning it in a loop concurrently (or running our tests), you might create a lot of caches, so we'd also probably need to provide a clean command.

[lishaduck]

Oh, better idea: have a single, shared readonly cache that only a single run write to. Use the presence of a cache.lock file to detect if another process is currently running, and don't try to write.