feat: lake.lock file for builds

[tydeu]

A feature frequently requested on Zulip (c.f. 1, 2, 3).

[tydeu]

I am currently stumped. I have no clue why this or #2384 is failing. The do not fail on my machine (in MSY?S2 or WSL), so it likely has to be some difference between how the CI and my local machine handle background processes.

[digama0]

You made an ABI breaking change to a type in Init, you most likely need to set interpreter.prefer_native in stage0/src/stdflib_flags.h and possibly do a stage0 update

[tydeu]

@digama0 That does not appear to be the bug. Looking at the logs, lake is working fine (the lock file is generated and waiting on properly). The test is simply not terminating once the script finishes for some reason.

FYI, I think the reason this did not cause ABI breakage is that FS.Mode is still a uint8_t and the name of the C symbol for Handle.mk has not changed.

[Kha]

This looks good but I'd also like to hear about potential future plans. Do we believe we'll want to end up with granular locking, e.g. per-module? What would that look like?

[Kha]

The test is simply not terminating once the script finishes for some reason.

Are we sure it's the end of the script and not fg that's blocking? Could the background process for some reason interfere?

[tydeu]

@Kha

Are we sure it's the end of the script and not fg that's blocking? Could the background process for some reason interfere?

I am not yet, but that is what I plan on testing today. However, my reason for believing it is the end of the script is that Lake background job does successfully resume, acquire the lock and begin building (as can be seen from the Building Test output).

[tydeu]

@Kha

Do we believe we'll want to end up with granular locking, e.g. per-module? What would that look like?

While theoretically useful, I am incline to avoid this. If the watchdog is merged into Lake, one lock for the server is fine. For the CLI, invoking multiple lake builds in parallel is already a bad idea (as it prevents internal build deduplication and adds Lake workspace overhead). Thus, a single per-Workspace build lock file seems sufficient.

[tydeu]

@Kha The last run confirms that the problem is on the script finish, not the fg (and pkill does not work).

[tydeu]

@Kha Update: It appears the problem is the process substitution. CTest is waiting on it finish before completing the test.