You received this message because you are subscribed to the Google Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/capnproto/cd5ce66c-b12e-4612-b383-32462f047f69n%40googlegroups.com.
|// The filesystem API|
|// This API is strictly synchronous because, unfortunately, there's no such thing as asynchronous|
|// filesystem access in practice. The filesystem drivers on Linux are written to assume they can|
|// block. The AIO API is only actually asynchronous for reading/writing the raw file blocks, but if|
|// the filesystem needs to be involved (to allocate blocks, update metadata, etc.) that will block.|
|// It's best to imagine that the filesystem is just another tier of memory that happens to be|
|// slower than RAM (which is slower than L3 cache, which is slower than L2, which is slower than|
|// L1). You can't do asynchronous RAM access so why asynchronous filesystem? The only way to|
|// parallelize these is using threads.|
|// All KJ filesystem objects are thread-safe, and so all methods are marked "const" (even write|
|// methods). Of course, if you concurrently write the same bytes of a file from multiple threads,|
To view this discussion on the web visit https://groups.google.com/d/msgid/capnproto/CANPfQguo2bq4G0tWPeAgzphdSpU4isMkxRUzNmxjCjyvvaxO0w%40mail.gmail.com.
Some operating systems (*cough* Windows *cough*) don't support non-blocking file (or inter-process pipe) I/O without some unreliable hacks. AFAICT.