From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 9 Jun 2009 19:20:28 -0400 From: Bhanu Nagendra Pisupati To: 9fans@9fans.net In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [9fans] critique of sockets API Topicbox-Message-UUID: 084960c0-ead5-11e9-9d60-3106f5b1d025 First off, I really am a big fan of filesystem interfaces as used in Plan 9 - after all my PhD work was based on the model :) My objective here is to debate and understand how the points made in the paper relate to the Plan9 networking model. >> * 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. Well, select() or alt might or might not be required depending on whether you want your thread to wait till the read operation waiting for data from the network completes. You may argue that since threads are "cheap" in Plan9 you can afford to have a thread wait on the read operation. But that to me is a different question... >> * 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. Whether the IO is synchronous or not, there is this read()->process()->read()... alternating sequence of operations that is required, wherein the application has to explicitly go fetch data from the network using the read operation. To borrow text from the paper: The API does not provide the programmer a way in which to say, "Whenever there is data for me, call me to process it directly." >> * 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. The question was meant to ask as to how easy it is to programmatically use the filesystem interface in a multi home network. But I agree that support for multiple network interfaces in Plan9 is way superior.