From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <71551546922daa465e9934a8b3f4b90e@quanstro.net> Date: Thu, 11 Jun 2009 19:34:22 -0400 Message-ID: <9ab217670906111634m735febcfsaac86e35e9a7d635@mail.gmail.com> From: "Devon H. O'Dell" To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [9fans] critique of sockets API Topicbox-Message-UUID: 098f1d4e-ead5-11e9-9d60-3106f5b1d025 2009/6/11 Eris Discordia : >> 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. s/could be/is/ >>From real world product experience across multiple operating systems and architectures.