2009/4/21 erik quanstrom <quans...@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
