Re: [9fans] critique of sockets API

[erik quanstrom <quanstro@quanstro.net>]

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