From owner-freebsd-net@FreeBSD.ORG Tue Oct 19 11:33:27 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C52D916A4CE for ; Tue, 19 Oct 2004 11:33:27 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1F0B43D5C for ; Tue, 19 Oct 2004 11:33:26 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 57685 invoked from network); 19 Oct 2004 11:32:26 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 19 Oct 2004 11:32:26 -0000 Message-ID: <4174FB8C.F63D278A@freebsd.org> Date: Tue, 19 Oct 2004 13:33:32 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Ronald F. Guilmette" References: <67378.1098167428@monkeys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@FreeBSD.ORG cc: Garrett Wollman Subject: Re: aio_connect ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2004 11:33:27 -0000 "Ronald F. Guilmette" wrote: > > In message <200410182138.i9ILcvmG095282@khavrinen.lcs.mit.edu>, you wrote: > > >< 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 day. > 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. -- Andre