Don't leak memory in background eval

[jneem]

This fixes a memory leak in background evaluation, by running each background eval job in a separate process. This might be a little extreme: there's a middle ground where we run several eval jobs in a single process before killing it to reclaim the memory. This extreme approach has the advantage of being simpler and not having an additional knob to tune.

[yannham]

If I understand correctly, does this mean we don't dedup anymore, and just blindly spawn a new process as soon as we have a notification? Is that at risk of spawning many many processes during live editing?

[yannham]

Is this related to running the process in the background? Why do we need to keep deps now?

[jneem]

Because we spin up a new process for each job, we need to transfer over all the file contents (because the LSP's in-memory contents might be different to what's on disk). The dependency tracking allows us to send over only the file contents that the current eval depends on.

[jneem]

No, it should still only eval a single file at a time, although the mechanism is somewhat different: the main process has a single background thread in charge of the eval processes. The background thread spawns an eval process and then waits for it to finish. While it's waiting, new requests from the main thread can pile up in its channel. When it's done waiting, it drains all those requests and dedups them (in SupervisorState::handle_command).

I did just realize that we aren't killing the child when it times out, though, so let me fix that...

[yannham]

I see, thanks for the precision. The approach looks good to me: while there's space for fine-tuning, even if we waste a bit of resources spanning a lot of processes, as long as it doesn't happen in the main LSP thread, it's reasonable.