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
<quans...@quanstro.net> wrote:
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
