From mboxrd@z Thu Jan  1 00:00:00 1970
MIME-Version: 1.0
In-Reply-To: <191db84e421c825f67aa18631ffc0884@coraid.com>
References: <7c22175ab60f8a5ae2cf894d462b29e5@9netics.com>
	<191db84e421c825f67aa18631ffc0884@coraid.com>
Date: Thu, 23 Apr 2009 13:07:58 +0800
Message-ID: <140e7ec30904222207r36c41d7dgbae9c320e79cfc29@mail.gmail.com>
From: sqweek <sqweek@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Plan9 - the next 20 years
Topicbox-Message-UUID: ef384c9a-ead4-11e9-9d60-3106f5b1d025

2009/4/21 erik quanstrom <quanstro@coraid.com>:
>> http://moderator.appspot.com/#15/e=c9&t=2d
>
> "You must have JavaScript enabled in order to use this feature.
>
> cruel irony.

No silver bullet, unfortunately :)

Ken Thompson wrote:
| HTTP is really TCP/IP - a reliable stream transport. 9P is a
| filesystem protocol - a higher level protocol that can run over
| any of several transfer protocols, including TCP. 9P is more
| NFS-like than HTTP.
|
| HTTP gets it's speed mostly by being one way - download. Most
| browsers will speed up loading by asking for many pages at once.
|
| Now for the question. 9P could probably be speeded up, for large
| reads and writes, by issuing many smaller reads in parallel rather
| than serially. Another try would be to allow the client of the
| filesystem to issue asynchronous requests and at some point
| synchronize. Because 9P is really implementing a filesystem, it
| will be very hard to get any more parallelism with multiple outstanding
| requests.

 I followed it up with a more focused question (awkwardly worded to
fit within the draconian 250 character limit), but no response yet:
"Hi Ken, thanks for your 9p/HTTP response. I guess my real question
is: can we achieve such parallelism transparently, given that most
code calls read() with 4k/8k blocks. The syscall implies
synchronisation... do we need new primitives? h8 chr limit"

-sqweek