Re: [9fans] critique of sockets API

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

> 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 
<quanstro@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
>