From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Tue, 9 Jun 2009 19:24:43 -0400 Message-ID: <3aaafc130906091624q69a421e7l3d97b9cde0501f2b@mail.gmail.com> From: "J.R. Mauro" To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] critique of sockets API Topicbox-Message-UUID: 0868148e-ead5-11e9-9d60-3106f5b1d025 On Tue, Jun 9, 2009 at 7:20 PM, Bhanu Nagendra Pisupati wrote: > 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 :) Did you do this on Plan 9 or bring some of the filesystem sanity of another= OS? > 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 nee= ds >>> to perform 2 system calls (select/read or alt/read) >> >> alt ? which is not required ? is not a system call. =A0only a read or wr= ite >> 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 fro= m > the network completes. You may argue that since threads are "cheap" in Pl= an9 > you can afford to have a thread wait on the read operation. But that to m= e > 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. =A0you can use threads to do i/o asynch w.r.t. your applicati= on, >> 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 th= e > 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. =A0why would using a filsystem (or not) make any differen= ce >> in the ability to multihome? >> >> by the way, plan 9 beats the pants off anything else i've used for >> multiple >> network / interface support. =A0it's support for mulitple ip stacks is q= uite >> neat. > > The question was meant to ask as to how easy it is to programmatically us= e > the filesystem interface in a multi home network. But I agree that suppor= t > for multiple network interfaces in Plan9 is way superior. > >