Re: [9fans] critique of sockets API

[Eris Discordia <eris.discordia@gmail.com>]

> 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

Of course it is single-threaded operation. That's the very idea behind 
using callbacks. Originally they were used to allow applications to do 
asynchronous I/O on earlier Windows incarnations that had no concept of 
threading. When threading became available it was correctly considered 
hazardous, as with any other form of concurrency, so it was and is avoided 
unless absolutely necessary. Callbacks survived the introduction of 
threading.

There are actually three thinkable options here: read-and-wait 
(synchronous), subscribe-and-continue (asynchronous using callback), and 
continue-until-notified (asynchronous using message queue). My point was 
that as of some time ago, more than a decade I believe, Windows began 
offering all three options which may be used on their own or in tandem. The 
three options can be sorted in order of increasing initial cost: callback, 
message queue, thread (and/or "lightweight process"). Average cost reverses 
that ordering. The application determines which strategy is better.

On the subject of who gets to process a certain event on Windows it should 
be noted that any process/thread that subscribes for an event will be 
notified, if an opportunity for subscription is provided in the first 
place. In case of a read other processes/threads have no notion that a 
specific read has been requested and they will never want to process the 
results of a read they haven't requested. Interface and other events that 
may concern more than one process/thread, on the other hand, can be 
processed by any worker that opts to process them. A chain of handlers with 
varying priorities is very easy to construct within this framework.

> 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.

I might as well repeat myself: choice of strategy depends on the 
application. Given choice programmers can decide on which strategy or 
combination of strategies works best. Without choice, well, they will just 
live with what's available. It is common with Windows programmers to use a 
combination of threading, callbacks, and synchronous I/O that best 
represents the application's workings. GUI is often run in its own thread 
which is made to wait only on I/O that crucially affects future 
interactions, e.g. a user "Open File" request. Processing of sporadic 
network events, e.g. reports from a network resource, is done in auxiliary 
message queues. Light network operations are delegated to a single thread 
that uses callbacks. Only heavy network operations are aggressively 
threaded.

Most notable here is the fact that allowing for various compatible options 
to grow within the same system can only enrich it while insisting on "The 
One Right Way" always leaves open the question of whether a different 
choice of strategy on the same platform, were a different choice available, 
would have yielded better results.

> are you saying the author(s) had their windows blinders on
> and might not have considered other options?

I believe at this point it is clear that all thinkable options are 
available on the platform you refer to as (horse) "blinders" but that 
really isn't important. The author(s) had criticized a specific I/O model 
without mentioning, or probably even knowing, that alternatives existed and 
could be profiled for tangible, definitive results. I merely pointed that 
out.

--On Thursday, June 11, 2009 08:16 -0400 erik quanstrom 
<quanstro@quanstro.net> wrote:

> 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