9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "J.R. Mauro" <jrm8005@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] critique of sockets API
Date: Tue,  9 Jun 2009 19:24:43 -0400	[thread overview]
Message-ID: <3aaafc130906091624q69a421e7l3d97b9cde0501f2b@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0906091855210.385@tank.cs.indiana.edu>

On Tue, Jun 9, 2009 at 7:20 PM, Bhanu Nagendra
Pisupati<bpisupat@cs.indiana.edu> 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 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:
> <snip>
> 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."
> </snip>
>
>
>>> * 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.
>
>



  reply	other threads:[~2009-06-09 23:24 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.998.1244574121.1513.9fans@9fans.net>
2009-06-09 23:20 ` Bhanu Nagendra Pisupati
2009-06-09 23:24   ` J.R. Mauro [this message]
2009-06-09 23:33   ` Devon H. O'Dell
2009-06-10  3:33     ` Gary Wright
2009-06-10  0:07   ` erik quanstrom
2009-06-10  0:34     ` erik quanstrom
2009-06-11  7:07     ` Eris Discordia
     [not found] <mailman.1.1244808001.26495.9fans@9fans.net>
2009-06-13  1:39 ` Bhanu Nagendra Pisupati
     [not found] <b0a72b5826eb44300d3603f585859910@quanstro.net>
2009-06-11 14:54 ` Eris Discordia
2009-06-11 18:24   ` erik quanstrom
2009-06-11 21:21     ` Eris Discordia
2009-06-11 23:41       ` erik quanstrom
2009-06-12  4:32         ` Paul Lalonde
2009-06-12  7:19         ` Eris Discordia
     [not found]     ` <D9FE8C51EE2D568C05E555DD@192.168.1.2>
2009-06-11 23:34       ` Devon H. O'Dell
2009-06-12  7:21         ` Eris Discordia
2009-06-11 12:16 erik quanstrom
     [not found] <mailman.1.1244635201.19660.9fans@9fans.net>
2009-06-10 23:46 ` Bhanu Nagendra Pisupati
     [not found] <mailman.1007.1244590421.1513.9fans@9fans.net>
2009-06-10 22:50 ` Bhanu Nagendra Pisupati
2009-06-11 12:34   ` erik quanstrom
  -- strict thread matches above, loose matches on Subject: below --
2009-06-09 18:49 Bhanu Nagendra Pisupati
2009-06-09 18:59 ` erik quanstrom
2009-06-09 22:11 ` Russ Cox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3aaafc130906091624q69a421e7l3d97b9cde0501f2b@mail.gmail.com \
    --to=jrm8005@gmail.com \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).