From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <93b18d47a6e4af99d306a91208ec1553@quanstro.net> From: erik quanstrom Date: Tue, 9 Jun 2009 14:59:35 -0400 To: 9fans@9fans.net In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: Re: [9fans] critique of sockets API Topicbox-Message-UUID: 07f97f2e-ead5-11e9-9d60-3106f5b1d025 On Tue Jun 9 14:50:58 EDT 2009, bpisupat@cs.indiana.edu wrote: > Interesting read: > http://cacm.acm.org/magazines/2009/6/28495-whither-sockets/fulltext > > If I am right, the filesystem based networking interface offered by Plan 9 > has the three limitations discussed here: > * performance overhead: app requesting data from a socket typically needs > to perform 2 system calls (select/read or alt/read) alt — which is not required — is not a system call. only a read or write is required. > * lack of an "kernel up-call API": which allows the kernel to inform an > app each time network data is available plan 9 uses synchronous i/o, so this statement doesn't make sense in plan 9. you can use threads to do i/o asynch w.r.t. your application, but the i/o itself is still synchronous w.r.t. the kernel. > * hard to implement "multi homing" with support for multiple network > interfaces i have no idea how this relates to the use of a fs in implementing the network stack. why would using a filsystem (or not) make any difference in the ability to multihome? by the way, plan 9 beats the pants off anything else i've used for multiple network / interface support. it's support for mulitple ip stacks is quite neat. - erik