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"

    Relevant Pages

    • Re: UNINTERRUPTABLE task state.
      ... > is in UNINTERRUPTIBLE state when it sleeps blocking all signals. ... The kernel performs magic on behalf of processes. ... sends a request to the kernel, and the kernel tries to service the request. ... and parking it in a queue. ...
    • Re: Why processes on linux loses signals?
      ... next SIGIO that indicates readiness of another filedescriptor -- ... some request to oracle db and that request stuck in the event ... There are other examples like this, all involving lost signals. ... the unreliability, and why signals should be unreliable on linux ...
    • Why processes on linux loses signals?
      ... processes on linux loses signals. ... next SIGIO that indicates readiness of another filedescriptor -- ... some request to oracle db and that request stuck in the event ... There are other examples like this, all involving lost signals. ...
    • Re: Design Questions on Termination
      ... not need signals at all for my implementation. ... - it is used to request a config reload request. ... get a termination request, how do I gracefully shutdown that thread? ... replace the selectwith any other blocking operation (e.g. openssl ...
    • Re: SETI and the Detection of ID
      ... nature like creationists are saying about the feature of nature called ... messy signals," Cullers notes. ... I requested a formal cite. ... Now in general that is taken as a request ...