Re: aio_connect ?

From: Ronald F. Guilmette (
Date: 10/19/04

  • Next message: Max Laier: "Re: ALTQ CDNR"
    To: Andre Oppermann <>
    Date: Tue, 19 Oct 2004 12:26:12 -0700

    In message <>, 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:

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

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

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

    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.

    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!

    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.
    _______________________________________________ mailing list
    To unsubscribe, send any mail to ""

  • Next message: Max Laier: "Re: ALTQ CDNR"