From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 11 Jun 2009 22:21:58 +0100 From: Eris Discordia To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: In-Reply-To: <71551546922daa465e9934a8b3f4b90e@quanstro.net> References: <71551546922daa465e9934a8b3f4b90e@quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Re: [9fans] critique of sockets API Topicbox-Message-UUID: 0978df7a-ead5-11e9-9d60-3106f5b1d025 > 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=20 actual demonstration or for going beyond the "talk talk talk" stage. I can, = however, present one simple case: in some applications asynchronous name=20 resolving is a must and it can be realized by either of threads or=20 callbacks. Crawlers and scanners come to mind. Spawning threads for DNS=20 requests could be more costly than registering a set of callbacks within=20 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=20 rather small. Most calls are wrappers for more basic calls but we don't=20 want to go into that. > i think you're trying to argue that =E2=80=94 a priori =E2=80=94 choice = is good? I believe it is. How many of us are using strictly RISC machines on our=20 desks today? Extending the set of available primitives and adding to the=20 complexity of each primitive both are natural steps in the development of=20 computer systems as they see more use. Limiting options doesn't seem to me=20 to be an effective way of encouraging good programming practice. It can,=20 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=20 advantageous? I think the next step would be incorporating them into the=20 system. A process that in due time will make the system less simple and=20 easy to change but more immediately useful. I see this more as a difference of intended audience than a difference of=20 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=20 option that would let me do my job easier, faster, and, of course, more=20 properly. --On Thursday, June 11, 2009 14:24 -0400 erik quanstrom=20 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 =E2=80=94 a priori =E2=80=94 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 >