Date: Tue, 19 Oct 2004 22:56:18 +0200 From: Andre Oppermann <andre@freebsd.org> To: "Ronald F. Guilmette" <rfg@monkeys.com> Cc: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Subject: Re: aio_connect ? Message-ID: <41757F72.A36AD263@freebsd.org> References: <72574.1098213972@monkeys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Ronald F. Guilmette" wrote: > > In message <4174FB8C.F63D278A@freebsd.org>, you wrote: > > >> Anyway, upon further reflection (and further RTFM'ing) I am now inclined > >> towards a distinct dislike for the entire aio_*() family of functions > >> because, as I just now realized, they provide the programmer with a > >> synchronous way (i.e. the aio_error function) of checking for inherently > >> _asynchronous_ events, i.e. I/O completions. All things considered, I > >> think that I personally would prefer to receive such notifications (of > >> asynchronous I/O completions) via interrupts... er... I mean via signals. > >> > >> (I suppose that there is some way of doing that, but I confess that I per- > >> sonally have never come across it, so if anybody wants to educate me, then > >> by all means please do so.) > > > >man kqueue. > > I am familiar with kqueue, and I wrote an early example program to illustrate > its use: > > http://www.monkeys.com/freeware/kqueue-echo.c > > But that facility (kqueue/kevent) does not provide the kind of asynchronous > I/O completion interrupts that I was asking about. Rather, it is just a > different (and significantly more efficient) way of doing essentially the > same things as you can do with either select() or poll(). What other events than aio_connect() you are interested in? > >And have a look at libevent by Niels Provos. Saves the day. > > Hummm... I did a google search on that and started to read this page: > > http://www.monkey.org/~provos/libevent/ > > (As a monkey myself, I supposed that I should have already known about this, > but I didn't. :-) > > Anyway, reading that page was rather enlightening, and it gave me some other > clues that I tracked down. Those caused me to realize that the aio_*() > family of functions is _not_ hopeless after all, and that they _can_ trigger > exactly the kinds of asynchronous I/O completion signals that I was asking > for... although that fact is very poorly (un-)documented in the relevant > FreeBSD man pages (on 4.10-RELEASE) for the aio_*() functions. (Those man > pages need a LOT of work.) Feel free to submit updates for the man pages. AFAIK there are certain problems with AIO in FreeBSD and you not only the man pages need some work but the implementation too. > Anyway, as I have just learned, the async I/O control blocks used by, for > example, aio_read() and aio_write() contain a field named `aio_sigevent' > that allows the user to request, in advance, that some specific signal be > delivered when the requested I/O operation completes. This is _exactly_ > the kind of thing that I earlier said would be a Good Thing To Have. I still don't understand what exactly you are trying to achieve (The Big PictureTM). > So anyway, I am pleased to see that, after all, it _is_ possible to pro- > gramatically ask to be interrupted (via a signal) when a given async I/O > operation completes. That's the good news. The bad news is that... just > as I noted in the posting that began this thread... there is no such thing, > at present, as an aio_connect() function. :-( Bummer! Ah, you want to be interrupt driven instead of being poll-event driven as with poll/select and kqueue? What about extending kqueue with a async signaling mechanism? Would that make your stuff work? I think doing this would be easier and more powerful than fixing all the aio stuff. The kqueue will queue all events and then signal them via SIGwhatever so you can do one poll on the kqueue and dequeue all pending events. Plus you can schedule all new works which then will be reported to you via the same mechanism again. I've added Jean-Mark Gurney to the CC list. He has done some more involved work on kqueue recently. He probably has the best overview if/how to make this work with kqueue. > Anyway, I'd like to now repeat the ``request for enhancement'' that I put > forward in the posting I made that started this thread. The reasons why > the functionality of such a (hypothetical) new function would _not_ be > redundant with the functionality provided by other kernel calls (e.g. > connect() on a NOWAIT descriptor, followed by select()/poll()) are now > quite clear and evident. A call to connect() followed by a call to select() > or poll() to detect completion of the asynchronous connect() is a funda- > mentally _synchronous_ (manual polling) approach to the problem of detecting > the completion of an asynchronous connect() attempt. But if there existed > an aio_connect() function, then via the `aio_sigevent' field of the > async I/O control block (struct aiocb) passed to such a function the > caller could request _asynchronous_ notification (via a signal) of the > subsequent completion of the asynchronous aio_connect() call. (And let > me say that I dearly wish that I had _exactly_ this functionality RIGHT > NOW. It would help a lot for one project I am working on.) > > In short, many of the reasons for having an aio_read() function are, in > my opinion, equally applicable to a (hypothetical) aio_connect() function. > In an ideal Universe... or even in just an ideal kernel... both should > exist, as they both would/could provide an asynchronous (signal-based) > notifications of completion events... a kind of functionality that clearly > cannot be duplicated with any other existing kernel calls, or even with > any combinations thereof. > > Unless someone comes up with a compelling counter-argument, I will shortly > be submitting a ``request for enhancement'' PR that asks specifically for > the addition of a new aio_connect() kernel call. You can submit as many requests for enhancements as you whish as long as you attach the patch to implement it. Otherwise they will sit in GNATS for a long time. AIO has been very much neglected and there is no active maintainer for it. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41757F72.A36AD263>