Date: Fri, 20 Jul 2012 21:02:38 +0200 From: Jilles Tjoelker <jilles@stack.nl> To: davidxu@FreeBSD.org Cc: George Neville-Neil <gnn@FreeBSD.org>, arch@FreeBSD.org Subject: Re: aio in GENERIC? Message-ID: <20120720190238.GA90393@stack.nl> In-Reply-To: <50075072.5050906@gmail.com> References: <3CE55F29-A5B2-44A7-8854-1ED38BAE6F16@FreeBSD.org> <50075072.5050906@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jul 19, 2012 at 08:10:26AM +0800, David Xu wrote: > On 2012/7/18 22:43, George Neville-Neil wrote: > > I was wondering why aio is not yet in GENERIC. Now that it's > > properly locked and all. > I think one of the problem in the AIO code is it allows user code to > pass pipe, socket and other file handles to kernel, however it may > not work well, the AIO threads may be blocked forever. I suggest to > disable support for socket or pipe except normal file or disk device. Yes, there seems to be an implicit assumption in the POSIX spec that AIO is only used on "fast" devices. There is no mention how a request should be cancelled that has already partially committed, such as a large write on a blocking socket, and there is text in the aio_cancel() description suggesting that it can only remove queued requests: ] The value AIO_NOTCANCELED shall be returned if at least one of the ] requested operation(s) cannot be canceled because it is in progress. An implementation might take more liberty with the cancellation implicit in exec or exit (because status need not be returned) but the FreeBSD implementation does not. Ideally, aio_cancel() and exec/exit would abort operations in progress at least in all situations where a signal would interrupt a corresponding blocking call. Additionally, it may be helpful for very large requests that need to be split up, not to start new I/O requests for parts that have not been started yet (probably only for exec/exit). The code only considers an operation on a socket "in progress" if the socket buffer has had some data/space but this is insufficient because another operation might use up that before this one starts and a large blocking write may not fit into the socket buffer at once. > it should either fully support it or do not support it at all, not > half-baked. Agreed. The current code may get stuck indefinitely if an operation blocks indefinitely. Depending on what applications actually use this, you could try failing with [EOPNOTSUPP] if aio_read/aio_write/aio_fsync is attempted on an unsupported file type. -- Jilles Tjoelker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120720190238.GA90393>