Reading the comment of issue https://github.com/WebAssembly/WASI/issues/247#issuecomment-610683399, I found I should know the background well: Why do read
and write
receive array of strings (iovec
s), instead of just a string?
Doesn't providing only simpler APIs suffice?
CC @Dan Gohman
The short answer is, CloudABI chose to do it this way, and we haven't changed it yet.
The longer answer is:
readv/writev have better performance than copying everyting into one big buffer or than making multiple read/write calls, and in some cases there are subtle semantic reasons where one wants to read/write with multiple buffers and have the OS treat it like a single system call.
And then the observation is, given that we want readv/writev, and that they provide a superset of the functionality and performance of read/write, do we also need read/write?
The main thing plain read/write provide is convenience for people writing code by hand. That's not super important in a system like CloudABI because very few people write system calls by hand. But in WASI, we seem to have a lot higher proportion of people coding to the raw WASI APIs by hand, especially right now as people are experimenting with it.
I got it. Thank you!
I found an interesting rule of readv/writev related to this topic: From man of readv(2) http://man7.org/linux/man-pages/man2/readv.2.html
The data transfers performed by readv() and writev() are atomic: the
data written by writev() is written as a single block that is not
intermingled with output from writes in other processes (but see
pipe(7) for an exception); analogously, readv() is guaranteed to read
a contiguous block of data from the file, regardless of read opera‐
tions performed in other threads or processes that have file descrip‐
tors referring to the same open file description (see open(2)).
Should this rule be documented also in WASI? If so, the difference between readv/writev and read/write might be clearer. And read/write could be implemented with relatively lower overhead.
Yes, it should be documented in WASI. If you're interested in submitting a PR for this, it should go in wasi_ephemeral_fd.witx
.
There are a few subtleties to watch out for:
The document you quoted above is the Linux man page; in POSIX, the atomicity guarantee only applies to normal files and symbolic links, and not other types of streams like pipes, terminals, or sockets. It's unclear if Linux really intends to make a stronger guarantee here or if Linux's wording is just imprecise.
POSIX reference: https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_09_07
WASI should probably follow POSIX here, unless we happen to know that other OS's provide stronger guarantees as well.
And, in POSIX, the same guarantees are applied to read
and write
as well, so read
and write
really are equivalent to readv
and writev
with one buffer.
Last updated: Dec 23 2024 at 12:05 UTC