but given that plan 9 is about having a system that's easy
to understand and modify, i would think that it would be
tough to demonstrate that asyncronous i/o or callbacks
could make the system (or even applications) simplier.
i doubt that they would make the system more efficient,
either.
do you have examples that demonstrate either?
I can't claim I have anything in code which would be necessary for an
actual demonstration or for going beyond the "talk talk talk" stage. I can,
however, present one simple case: in some applications asynchronous name
resolving is a must and it can be realized by either of threads or
callbacks. Crawlers and scanners come to mind. Spawning threads for DNS
requests could be more costly than registering a set of callbacks within
one thread and then harvesting the results within that same thread.
one can build what's needed. compare just r?fork and exec
with all the spawn variants windows has.
The actual number of calls in CreateThread and CreateProcess family is
rather small. Most calls are wrappers for more basic calls but we don't
want to go into that.
i think you're trying to argue that — a priori — choice is good?
I believe it is. How many of us are using strictly RISC machines on our
desks today? Extending the set of available primitives and adding to the
complexity of each primitive both are natural steps in the development of
computer systems as they see more use. Limiting options doesn't seem to me
to be an effective way of encouraging good programming practice. It can,
however, successfully discourage potential middle users.
that's not the position i subscribe to. and since plan 9
is simple and easy to change, it makes an ideal system
for someone who wants to try new things.
And after the new things are tried out and, one may hope, proven
advantageous? I think the next step would be incorporating them into the
system. A process that in due time will make the system less simple and
easy to change but more immediately useful.
I see this more as a difference of intended audience than a difference of
taste or philosophy. The real question is whom you imagine as your system's
middle user: a wage-earning programmer or a researcher. Were I a programmer
who worked for pay I'd very much appreciate being given every possible
option that would let me do my job easier, faster, and, of course, more
properly.
--On Thursday, June 11, 2009 14:24 -0400 erik quanstrom
<quans...@quanstro.net> wrote:
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.
this is a very deep philosophical divide between windows and
systems like plan 9, and research unix. the approach the labs
took was to provide a minimal set of primatives from which
one can build what's needed. compare just r?fork and exec
with all the spawn variants windows has.
i think you're trying to argue that — a priori — choice is good?
but given that plan 9 is about having a system that's easy
to understand and modify, i would think that it would be
tough to demonstrate that asyncronous i/o or callbacks
could make the system (or even applications) simplier.
i doubt that they would make the system more efficient,
either.
do you have examples that demonstrate either?
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.
clearly if that position is accepted, computer science is a
solved problem; we should all put our heads down and just
code up the accepted wisdom.
that's not the position i subscribe to. and since plan 9
is simple and easy to change, it makes an ideal system
for someone who wants to try new things.
- erik
