named-lock
Cross-platform Rust library for cross-process named locks.
Repository Health
Technical Analysis
named-lock is a small, cross-platform Rust crate that provides named locks you can use to synchronize critical sections between separate processes. You create a lock by name, acquire a guard, and any other process using the same name will block until the guard is released.
It abstracts away the platform-specific machinery: on UNIX it is backed by lock files and flock, and on Windows by named mutexes created with CreateMutexW, exposing a single uniform API across both.
What You Get
- A
NamedLocktype created by name withcreate()and acquired vialock()/try_lock() - RAII guards that release the lock automatically when dropped
- Uniform cross-platform behavior backed by
flockon UNIX andCreateMutexWon Windows - A dedicated
Error/Resulttype for lock creation and acquisition failures
Common Use Cases
- Ensuring only one instance of a CLI or daemon runs at a time
- Serializing access to a shared file or hardware resource across processes
- Coordinating exclusive sections between cooperating programs on the same host
Under The Hood
Architecture - The crate is organized into a small src/lib.rs public surface plus platform modules unix.rs and windows.rs selected by cfg, and an error.rs defining the error type. NamedLock wraps a platform-specific handle: on UNIX it opens a lock file at $TMPDIR/<name>.lock (falling back to /tmp) and calls flock; on Windows it creates a named mutex via CreateMutexW. An in-process registry keyed by name (via once_cell + parking_lot) prevents the same process from opening duplicate underlying handles, and acquiring the lock returns an RAII guard that releases on drop.
Tech Stack - Pure Rust, edition 2018. It depends on once_cell for lazy statics, parking_lot (with arc_lock and send_guard) for the in-process guard, and thiserror for error types. Platform bindings come from libc on UNIX and the official windows crate (Win32 Foundation/Security/Threading features) on Windows.
Code Quality - The code is compact and idiomatic, with error handling routed through a thiserror-derived enum and Result alias. Tests use static_assertions to verify Send/Sync marker guarantees and uuid to generate unique lock names, exercising real cross-process semantics. The platform split keeps unsafe FFI confined to the OS modules.
API Design - The public API is deliberately minimal: create a lock by name, call lock() or try_lock(), and use the returned guard. This mirrors the ergonomics of the standard library’s Mutex while extending the concept across process boundaries, so the learning curve is shallow for anyone familiar with Rust locking.