YAMAMOTO Yuji (Apr 10 2020 at 07:41): YAMAMOTO Yuji (Apr 10 2020 at 07:41):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 (iovecs), instead of just a string?
Doesn't providing only simpler APIs suffice?
Till Schneidereit (Apr 10 2020 at 11:29):CC @Dan Gohman
Dan Gohman (Apr 10 2020 at 15:07):The short answer is, CloudABI chose to do it this way, and we haven't changed it yet.
Dan Gohman (Apr 10 2020 at 15:09):The longer answer is:
Dan Gohman (Apr 10 2020 at 15:09):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.
Dan Gohman (Apr 10 2020 at 15:10):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?
Dan Gohman (Apr 10 2020 at 15:12):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.
YAMAMOTO Yuji (Apr 13 2020 at 01:33):I got it. Thank you!
YAMAMOTO Yuji (Apr 13 2020 at 08:41):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.
Dan Gohman (Apr 14 2020 at 13:56):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.
Dan Gohman (Apr 14 2020 at 13:56):There are a few subtleties to watch out for:
Dan Gohman (Apr 14 2020 at 13:59):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.
Dan Gohman (Apr 14 2020 at 13:59):POSIX reference: https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_09_07
Dan Gohman (Apr 14 2020 at 14:00):WASI should probably follow POSIX here, unless we happen to know that other OS's provide stronger guarantees as well.
Dan Gohman (Apr 14 2020 at 14:02):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: Nov 22 2024 at 16:03 UTC