[Dovecot] Design: Asynchronous I/O for single/multi-dbox

[Edgar Fuß]

> 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.