andre at freebsd.org
Tue Oct 19 04:33:27 PDT 2004
"Ronald F. Guilmette" wrote:
> In message <200410182138.i9ILcvmG095282 at khavrinen.lcs.mit.edu>, you wrote:
> ><<On Sun, 17 Oct 2004 13:19:45 -0700, "Ronald F. Guilmette" <rfg at monkeys.com> said:
> >> I'm sitting here looking at that man pages for aio_read and aio_write,
> >> and the question occurs to me: ``Home come there is no such thing as
> >> an aio_connect function?''
> >Mostly because there is no need, since connect() doesn't transfer any
> >data; it just establishes a connection. If the socket is put in
> >non-blocking mode, connect() will take place in the background.
> That is a very interesting point, and one which I am now pondering.
> I myself _have_ in fact done what you are talking about before, i.e.
> starting up a non-blocking connect and then coming back later on with,
> say, either select() or poll() to see if it has finished. So I _do_
> know how to do what you are describing. But thinking about it now,
> I'd just like to say that it seems to me that that approach may have
> some significantly different semantics than the hypothetical aio_connect()
> function that I had suggested. (But then again, maybe not. I'll have
> to give it some more thought.)
> 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. And have a look at libevent by Niels Provos. Saves the
> P.S. And before anybody lambasts me about the head and neck for even
> suggesting the use of signals to indicate I/O completions, allow me to
> just say that yes, I _do_ undertstand that this would be quite costly,
> but for some applications, the cost would be acceptable.
More information about the freebsd-net