From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] Essay: Is network transparency something bad? From: rog@vitanuova.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Thu, 24 Oct 2002 18:54:50 +0100 Topicbox-Message-UUID: 0c5339a2-eacb-11e9-9e20-41e7f4b1d025 > But I don't think there's a single right answer to this. As we perl > programmers often say, "there's more than one way to do it." i think plan 9's approach is better than the more usual "network transparency" where a function or method invocation is turned into an RPC behind your back. at least in the plan 9 way, it is well documented that all system calls can potentially block for a long period of time, and they have error returns that can describe the arbitrary errors that can be associated with network transfers. so it's quite possible to write programs in the light of that knowledge (a decent threads library makes that easier too). i don't think it's so easy with, for instance, Java RMI (but i'd be glad to be contradicted). it's interesting to see what *does* lock up when a file access takes an unexpectedly long time (e.g. accessing the dump fs). for instance acme locks while it's opening a file; rio locks when plumbing a file. rog.