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. 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.)
--On Tuesday, June 09, 2009 20:07 -0400 erik quanstrom
<quans...@quanstro.net> wrote:
On Tue Jun 9 19:22:39 EDT 2009, bpisu...@cs.indiana.edu wrote:
Well, select() or alt might or might not be required depending on
whether you want your thread to wait till the read operation waiting
for data from the network completes.
your thread will always wait until any system call completes;
they're all synchronous all the time. if you want your application
to do something else at the same time, you're going to need two
threads and a synch device (like a lock + shared memory or a channel).
read()->process()->read()... alternating sequence of operations that is
required, wherein the application has to explicitly go fetch data from
the network using the read operation. To borrow text from the paper:
<snip>
The API does not provide the programmer a way in which to say, "Whenever
there is data for me, call me to process it directly."
</snip>
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.
perhaps you think this is doging the question, but the cannonical
plan 9 approach to this is to note that it's easy (trivial) to have a n
reader threads and m worker threads s.t. i/o threads don't block
unless (a) there's nothing to i/o, or (b) the workers aren't draining
the queue fast enough; and s.t. worker threads don't block
unless (a) the i/o threads can't keep up. in this case, there is no
work to do anyway. consider these two types of threads;
let mb be a pointer to a message buffer.
thread type 1
for(;;)
mb <- freechan
read(fd, mb->wp, BUFSIZE);
mb -> fullchan
thread type 2;
for(;;)
mb <- fullchan
do stuff
mb -> freechan
if your server issues responses, it's easy to add thread type 3.
as you can see, this is a simple generalization of your case. (if we
have a queue depth of 0 and one thread 1 and one thread 2,
we will get your loop.) yet there should be no waiting.
The question was meant to ask as to how easy it is to programmatically
use the filesystem interface in a multi home network. But I agree that
support for multiple network interfaces in Plan9 is way superior.
i think the answer to your question is that programs don't care.
programs that take a cannonical network address are just as
happy to accept /net/tcp!www.example.com!http as they are to
accept /net.alt/tcp!www.example.com!http. for a short while
i ran a 10gbit network on /net.10g.
- erik
