WASI prototype design, implementation, and documentation.
This adds documents describing the WASI Core API, and an implementation in Wasmtime.
This commit is contained in:
49
docs/WASI-possible-future-features.md
Normal file
49
docs/WASI-possible-future-features.md
Normal file
@@ -0,0 +1,49 @@
|
||||
# Possible Future Features
|
||||
|
||||
This are features we're interested in, but don't have yet, and which will require
|
||||
some amount of design work.
|
||||
|
||||
## File Locking
|
||||
|
||||
POSIX's answer is `fcntl` with `F_SETLK`/`F_GETLK`/etc., which provide advisory
|
||||
record locking. Unfortunately, these locks are associated with processes, which
|
||||
means that if two parts of a program independently open a file and try to lock
|
||||
it, if they're in the same process, they automatically share the lock.
|
||||
|
||||
Other locking APIs exist on various platforms, but none is widely standardized.
|
||||
|
||||
POSIX `F_SETLK`-style locking is used by SQLite.
|
||||
|
||||
## File change monitoring
|
||||
|
||||
POSIX has no performant way to monitor many files or directories for changes.
|
||||
|
||||
Many popular operating systems have system-specific APIs to do this though, so
|
||||
it'd be desirable to come up with a portable API to provide access to this
|
||||
functionality.
|
||||
|
||||
## Scalable event-based I/O
|
||||
|
||||
POSIX's `select` and `poll` have the property that each time they're called,
|
||||
the implementation has to scan through all the file descriptors to report if any
|
||||
of them has I/O ready, which is inefficient when there are large numbers of
|
||||
open files or sockets.
|
||||
|
||||
Many popular operating systems have system-specific APIs that provide
|
||||
alternative ways to monitor large numbers of I/O streams though, so it'd be
|
||||
desirable to come up with a portable API to provide access to this
|
||||
functionality.
|
||||
|
||||
## Crash recovery
|
||||
|
||||
POSIX doesn't have clear guidance on what applications can expect their
|
||||
data will look like if the system crashes or the storage device is otherwise
|
||||
taken offline abruptly.
|
||||
|
||||
We have `fsync` and `fdatasync`, but even these have been a topic of
|
||||
[much discussion].
|
||||
|
||||
[much discussion]: https://wiki.postgresql.org/wiki/Fsync_Errors
|
||||
|
||||
Also, currently WASI's docs don't make any guarantees about things like
|
||||
`path_rename` being atomic.
|
||||
Reference in New Issue
Block a user