From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <20090421163812.B8BA65B24@mail.bitblocks.com> References: <6fca5b4a2b0c1df84043eddf28ce3f52@lsub.org> <20090421163812.B8BA65B24@mail.bitblocks.com> Date: Tue, 21 Apr 2009 17:59:06 +0100 Message-ID: From: roger peppe To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Plan9 - the next 20 years Topicbox-Message-UUID: ee5a4508-ead4-11e9-9d60-3106f5b1d025 2009/4/21 Bakul Shah : > In the pipelined case, from a server's perspective, client's > requests just get to it faster (and may already be waiting!). > It doesn't have to do anything special. =C2=A0What am I missing? you're missing the fact that without the sequence operator, the second request can arrive before the first request has completed, thus potentially making it invalid (e.g. it's invalid to read from a file that hasn't been opened). also, in many current server implementations, each request gets serviced in its own process - there's no guarantee that replies will come back in the same order as the requests, even if all the requests are serviced immediately. it would be possible to do a similar kind of thing by giving the same tag to the operations in a sequence, but i'm quite attached to the fact that a) the operations are otherwise identical to operations in the original pro= tocol b) a small bit of extra redundancy is useful for debugging. c) you can get Tendsequence (which is necessary, i now realise) by flushing the Tsequence with a request within the sequence itself.