handle = open(path, mode)
- this function can't fail. it's executed asynchronously. Does that mean you can successfully open("/nonexistent", mode); write() to it over and over again and only the commit() fails?
handle = create(path, mode, permissions) [...]
- mode=fail-if-exists: commit() fails if file already exists
- mode=replace-if-exists: commit() replaces file if it already exists s/commit/create/g
ret = pread(handle, buf, size, offset)
- just like pread(), [...] Hm, pread() works like pread()? What do I misunderstand?
ret = try_lock(handle)
- this isn't an asynchronous operation! it assumes that locking state is kept in memory, so that the operation will be fast. So does this only lock against the same process or how is locking state supposed to be in memory?
if backend doesn't support locking or it's slow, single-dbox should be used (instead of multi-dbox), because it doesn't need locking.
- returns success or "already locked" And if the backend doesn't support locking?
Async input streams' read() would work exactly as file_istream works for non-blocking sockets: It would return data that is already buffered in memory. If there's nothing, it returns EAGAIN. The FS API's set_input_callback() can be used to set a callback function that is called whenever there's more data available in the buffer. I don't understand what triggers that reading into memory. Is that supposed to happen automaticly in the background or has it to be initiated by the program?
- POSIX AIO isn't supported by Linux kernel. And even if it was, it only supports async reads/writes, not async open(). Doesn't help you, but NetBSD 5 does support Posix AIO, I think.