[Dovecot] Design: Asynchronous I/O for single/multi-dbox
ef at math.uni-bonn.de
Mon Mar 15 21:37:34 EET 2010
> 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
> 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.
More information about the dovecot