In message <[EMAIL PROTECTED]>, 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. _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
