File.downgradeLock says it's atomic, but uses flock which is not atomic

[xackus]

File.downgradeLock says:

Atomically modifies the lock to be in shared mode, without releasing it.

From flock(2) Linux man page:

Converting a lock (shared to exclusive, or vice versa) is not
guaranteed to be atomic: the existing lock is first removed, and
then a new lock is established. Between these two steps, a
pending lock request by another process may be granted, with the
result that the conversion either blocks, or fails if LOCK_NB was
specified. (This is the original BSD behavior, and occurs on
many other implementations.)

downgradeLock is used in src/Cache.zig.

[andrewrk]

Welp I think you found the cause of #9439

[uhthomas]

Is there an idea of where this is in the priority queue and when this may be looked at? Unfortunately we've had to disable Zig CC in our CI environment as around 80% of all builds were failing because of this. 😔

[andrewrk]

Is there an idea of where this is in the priority queue and when this may be looked at?

The 0.9.0 Milestone

[andrewrk]

I'm still interested in addressing this issue but it's a slightly lower priority since it didn't turn out to be the cause of #9439 after all. In fact, I suspect that some OS's actually do make changing lock types with flock atomic and I plan to look into that a little bit as part of diagnosing this issue. Anyway this is moving to 0.9.1 milestone to stay on track for our release date of Dec 20.

[xackus]

In fact, I suspect that some OS's actually do make changing lock types with flock atomic

Maybe downgrading. If upgrading was atomic, deadlocks would happen when two processes want to upgrade.