9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: David Leimbach <leimy2k@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] πp
Date: Fri, 15 Oct 2010 07:57:19 -0700	[thread overview]
Message-ID: <AANLkTikJ8wv6ogKYdDzXUY_gVJT_sFmTw9Beqp_8-4p2@mail.gmail.com> (raw)
In-Reply-To: <fb4f2b86c24173fe9cf941c0af8b4f23@plan9.bell-labs.com>

[-- Attachment #1: Type: text/plain, Size: 1967 bytes --]

2010/10/15 Sape Mullender <sape@plan9.bell-labs.com>

> Are we talking about πP or 9P?
>

It's about both.  I was just curious about how 9P was deficient in terms of
pipelining.  It might not be optimal for all cases of pipelining, but the
protocol seems to support it in certain cases just fine.

ΠP deals with it in a superior way, and I need to finish reading the paper
on it.


>
> ΠP doesn't have Twalk.  It has open, which combines clone, walk, and open
> from
> 9P.  Before you start jumping up and down and telling me that you can't
> open
> without revieing the qids from the walk (to check them for mount points),
> let
> me tell you that we are also tackling mount tables.  Mount tables will no
> longer
> match qids but longest prefix path names.
> We know the semantics are different.  But you have to look hard to find
> realistic situations where the difference matters.
>
> I intend to write a πP design document that explains the whole concept in
> excruciating detail.  There's a lot more to it than just changing walk and
> open.
>

I'm looking forward to it!


>
>        Sape
>
>
> > From: lucho@ionkov.net
> > To: 9fans@9fans.net
> > Reply-To: 9fans@9fans.net
> > Date: Thu Oct 14 23:13:59 CES 2010
> > Subject: Re: [9fans] πp
> >
> > It can't be dealt with the current protocol. It doesn't guarantee that
> > Topen will be executed once Twalk is done. So can get Rerrors even if
> > Twalk succeeds.
> >
> > 2010/10/13 Venkatesh Srinivas <me@acm.jhu.edu>:
> > >> 2) you can't pipeline requests if the result of one request depends on
> the
> > >> result of a previous. for instance: walk to file, open it, read it,
> close
> > >> it.
> > >> if the first operation fails, then subsequent operations will be
> invalid.
> > >
> > > Given careful allocation of FIDs by a client, that can be dealt with -
> > > operations on an invalid FID just get RErrors.
> > >
> > > -- vs
> > >
>
>

[-- Attachment #2: Type: text/html, Size: 2910 bytes --]

  parent reply	other threads:[~2010-10-15 14:57 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-13 19:46 Eric Van Hensbergen
2010-10-13 22:13 ` David Leimbach
2010-10-13 22:36   ` roger peppe
2010-10-13 23:15     ` David Leimbach
2010-10-14  4:25       ` blstuart
2010-10-13 23:24     ` Venkatesh Srinivas
2010-10-14 21:12       ` Latchesar Ionkov
2010-10-14 21:48         ` erik quanstrom
2010-10-14 22:14         ` dorin bumbu
2010-10-15 14:07           ` erik quanstrom
2010-10-15 14:45             ` Russ Cox
2010-10-15 15:41               ` Latchesar Ionkov
2010-10-15 21:13             ` dorin bumbu
2010-10-15 22:13               ` erik quanstrom
2010-10-15 23:30                 ` dorin bumbu
2010-10-15 23:45                   ` cinap_lenrek
2010-10-15 23:54                     ` dorin bumbu
2010-10-15  7:24         ` Sape Mullender
2010-10-15 10:41           ` hiro
2010-10-15 12:11             ` Jacob Todd
2010-10-15 13:06               ` Iruatã Souza
2010-10-15 13:23             ` Sape Mullender
2010-10-15 14:57           ` David Leimbach [this message]
2010-10-15 14:54         ` David Leimbach
2010-10-15 14:59           ` Francisco J Ballesteros
2010-10-15 16:19             ` cinap_lenrek
2010-10-15 16:28               ` Lyndon Nerenberg
2010-10-15 17:54                 ` Nemo
2010-10-15 17:49                   ` ron minnich
2010-10-15 18:56                     ` erik quanstrom
2010-10-15 16:31               ` Latchesar Ionkov
2010-10-15 16:40                 ` cinap_lenrek
2010-10-15 16:43                   ` Latchesar Ionkov
2010-10-15 17:11                     ` cinap_lenrek
2010-10-15 17:15                       ` Latchesar Ionkov
2010-10-15 19:10                 ` erik quanstrom
2010-10-15 19:16                   ` Latchesar Ionkov
2010-10-15 21:43                     ` Julius Schmidt
2010-10-15 22:02                       ` David Leimbach
2010-10-15 22:05                       ` John Floren
2010-10-15 16:45               ` ron minnich
2010-10-15 17:26                 ` Eric Van Hensbergen
2010-10-15 17:45                 ` Charles Forsyth
2010-10-15 17:45                   ` ron minnich
2010-10-15 18:03               ` Bakul Shah
2010-10-15 18:45               ` David Leimbach

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=AANLkTikJ8wv6ogKYdDzXUY_gVJT_sFmTw9Beqp_8-4p2@mail.gmail.com \
    --to=leimy2k@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).