From owner-freebsd-net@FreeBSD.ORG Sat Oct 23 16:52:19 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 0D42F16A4CE for ; Sat, 23 Oct 2004 16:52:19 +0000 (GMT) Received: from segfault-outgoing-helo.monkeys.com (segfault.monkeys.com [66.60.159.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBBD743D1D for ; Sat, 23 Oct 2004 16:52:18 +0000 (GMT) (envelope-from rfg@monkeys.com) Received: from segfault-nmh-helo.monkeys.com (localhost [127.0.0.1]) by segfault.monkeys.com (Postfix) with ESMTP id 7A38E54A7; Sat, 23 Oct 2004 09:52:18 -0700 (PDT) To: Igor Sysoev In-reply-to: Your message of Sat, 23 Oct 2004 00:25:30 +0400. <20041023002300.I91215@is.park.rambler.ru> Date: Sat, 23 Oct 2004 09:52:18 -0700 Message-ID: <7208.1098550338@monkeys.com> From: "Ronald F. Guilmette" cc: freebsd-net@freebsd.org 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: Sat, 23 Oct 2004 16:52:19 -0000 In message <20041023002300.I91215@is.park.rambler.ru>, you wrote: >On Thu, 21 Oct 2004, Ronald F. Guilmette wrote: > >> >I believe if you want to build a more maintainable, more adaptable, >> >more modularized program then you should avoid two things - the threads and >> >the signals. If you like to use a callback behaviour of the signals you could >> >easy implement it without any signal. >> >> OK. I'll bite. How? > >I'm sure you know it. Don't be too sure. The number of things that I _don't_ know is enormous! >Sorry, English is not my native language so I may >tell you only shortly. Your English seems perfect to me. >You can use two notification models. First is the socket readiness >for operations, second is the operation completeness. >In the first model you use usual read()/write() operations and learn >readiness using select()/poll()/kevent(). Correct, but that requires either (a) waiting or else (b) constantly re- checking the status without waiting, over and overt again. The efficiency of (b) is obviously very low, so most people, myself in- cluded, never want to use that approach. In the case if (a), as I have noted, if you have a program that is per- foprming operations of, say, _several_ different independent socket connections, then if you also have a "modular" program in which each module only uses select()/poll()/kevent() to wait for completion on the specific socket that it is handling, then the (bad) effect is that completions of various operations on _other_ sockets (that are being handled) by other/different modules) may not be serviced in a timely fashion, which can be very bad. or at least very inefficient. >In the second model you use aio_read()/aio_write() operations and learn >about their completeness using aio_suspend()/aio_waitcomplete()/kevent(). These are, I believe, just other ways of doing "polling" for completion, and they thus suffer all of the same problems as polling via select(), or poll(), or kevent(). >After you have got the notifications you would call your callback handlers >as well as the kernel would call your signal handlers. Yes, I do see what you mean here. However I can only say again that using aio_*() functions with their signaling capabilities provides the programmer with a totally asynchronous notification of the completion of _individual_ I/O operations, and that this is fundamentally different, semantically, from the kind of synchronous polling for completion of any one of a _set_ of pending I/O operations that may be performed via select(), or poll(), or kevent(), or aio_suspend(). Thus, I still do believe that the judicious use of the aio_*() functions with signaling could support a dramatically different programming style, especially for complex network clients and/or servers that must monitor and respond to events on various kinds of socket connections, all in the same single program.