From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <b2ccfafc64156b0c9db99014ce0fe93a@quanstro.net>
From: erik quanstrom <quanstro@quanstro.net>
Date: Thu, 11 Jun 2009 08:16:03 -0400
To: eris.discordia@gmail.com, 9fans@9fans.net
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: Re: [9fans] critique of sockets API
Topicbox-Message-UUID: 093c871e-ead5-11e9-9d60-3106f5b1d025

On Thu Jun 11 04:12:13 EDT 2009, eris.discordia@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