Date: Sat, 23 Oct 2004 09:52:18 -0700 From: "Ronald F. Guilmette" <rfg@monkeys.com> To: Igor Sysoev <is@rambler-co.ru> Cc: freebsd-net@freebsd.org Subject: Re: aio_connect ? Message-ID: <7208.1098550338@monkeys.com> In-Reply-To: Your message of Sat, 23 Oct 2004 00:25:30 %2B0400. <20041023002300.I91215@is.park.rambler.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7208.1098550338>