On Thu Jun 11 04:12:13 EDT 2009, eris.discor...@gmail.com wrote: > > i don't think i understand what you're getting at. > > it could be that the blog was getting at the fact that select > > funnels a bunch of independent i/o down to one process. > > it's an effective technique when (a) threads are not available > > and (b) processing is very fast. > > This might help: what he is getting at is probably the question of why not > make possible network applications that consist of a bunch of callbacks or > a mix of callbacks and listener/worker threads. Windows implements both > synchronous and asynchronous I/O. Threads are available. Callbacks, too, as > well as message queues.
are you saying the author(s) had their windows blinders on and might not have considered other options? my windows-fu is very low. but according to microsoft http://msdn.microsoft.com/en-us/library/aa365683(VS.85).aspx windows "asynchronous" (overlapped) i/o signals the calling thread, so the signal context is the original calling thread. unless ms' diagram is incorrect, this is a single threaded operation; only the i/o originator can process the event. so the plan 9 model would seem to me to be better threaded and i think the CSP-style of the plan 9 model makes it easier to reason about. and has already been implemented under unix without changing the kernel. see p9p. > Ideally, it is the programmer's informed choice > based on their understanding of their application's priorities whether to > use callbacks, listener/worker threads, message queues, or a combination. > Someone may find it worth the effort to compare these approaches on a > platform that provides both. (COM is notorious for implementing things > through callback that get some wrapping of one's head around them before > making sense.) there's plenty of overlapped i/o in plan 9 — it's in the disk and network device drivers. even stripping away the register fiddling, it's not an i/o model that's attractive; that's the reason all the details are hidden in the kernel. - erik
