Skip wrote: :there were discussions about aysnc syscalls. /sys/src/cmd/fcp.c is a :good example of why they're not needed. streaming and long delay :networks can be handled this way too, as was pointed out (by Russ i :think) at iwp9.
But there is one problem. Consider "lc". Usually you see walk clunk walk clunk walk open write clunk and also walk stat clunk walk open read clunk The problem is, how to know which RPCs to pack? I mean, to send without waiting for reply. Note that several different fids might be used in these dialogs, even though they come in a small time window from the same process. I tried to imagine how to bundle them, for using 9P over high latency links, and couldn't find a good way of doing it (after iwp9). In the end, I had to implement a couple of processes to bridge islands with good internal latency, connected by poor links. They try to refrain from sending requests by using cached directory entries (and data) to try to make such runs in one or two RPCs. The hard part is making it work well both for regular files and for synthesized files. We have a version that works reasonable well for both, (only connections multiplexed over the same file, eg. clone opens, are not handled properly). Our current version of the protocol has "file descriptors" that are fids in that they "mean" a path for a file, and are not fids in that more than one fid may map to the same descriptor, and also in that paths are sent along with the descriptor to make the server stateless (or to make clients think so). 9P is just great for use when latency is reasonable (or not too bad, with cfs), but to go further away and still be comfortable using remote files, I'd say we need another protocol. I'd love to be proved wrong :)
