WASI icon indicating copy to clipboard operation
WASI copied to clipboard

File locking

Open sunfishcode opened this issue 5 years ago • 10 comments

Sqlite and the Emscripten cache file are two cases where file locking has come up in real-world use cases.

The POSIX way to do file locking, with fcntl and F_SETLK/F_GETLK-style locks has the unfortunate property of being per-process, which is unfortunate both for being contrary to what applications actually want, and because we'd prefer to avoid exposing details like which host processes things are running in to wasm programs. (POSIX is considering fixing this, but until they do and systems update to the new mechanism, we need to work with what current systems provide.)

Here are some notes on a WASI file locking API might want to consider:

  • The API should support byte-range locks, but permit implementations to lock more than requested, potentially up to the whole file. For example, FreeBSD has fcntl locks with the unfortunate POSIX behavior, and flock with the desirable per-file-description behavior, however flock only supports locking whole files at a time.
  • Discretionary file locking only is probably enough for now. Mandatory locking isn't reliably available in many host environments.
  • A lock can be shared (multiple locks can be held at once) or exclusive (only one lock).
  • Only one lock can be held on a given byte range of a given file description at a time.
  • Locks can be upgraded from shared to exclusive.
  • For now, acquiring a lock blocks until the lock is available.
  • It may be useful to permit implementations to report that locking is unsupported on the host filesystem. Some old NFS implementations, and possibly other networked filesystems, don't support locking.

sunfishcode avatar May 20 '20 14:05 sunfishcode