Module apply_lock 

Advisory file lock used to serialize mutating operations against a single .socket/ directory.

Apply, rollback, repair, and remove can each rewrite manifest state and on-disk package files. Two of them running at once against the same project — common when a dev runs socket-patch apply while CI triggers a deploy hook, or when apply and a repair are stacked by a wrapper script — race on every file write. The lock turns that race into a clean refusal: the second invocation reports lock_held and exits non-zero, leaving the first to finish.

The lock file lives at <.socket>/apply.lock. It is created on demand (the parent .socket/ directory must exist first; callers get a clear error otherwise) and is never deleted — the file handle drop releases the OS-level advisory lock, but the inode sticks around for next time. That keeps the lock idempotent across restarts and avoids a race where two callers create the lock file at the same time.

Locking is advisory (flock(2) on Unix, LockFileEx on Windows via the fs2 crate). Non-cooperating writers (a user shelling rm -rf .socket/) are not stopped — but every socket-patch mutating command honors the lock, which is what matters in practice.

Structs

LockGuard

RAII guard for the apply lock.

Enums

LockError

Errors surfaced when acquiring the apply lock.

Functions

acquire

Try to acquire the apply lock at <socket_dir>/apply.lock.