Sometimes, I whish I could think faster.
The fact request can be pipelined like this -I mean, by taking care of the
fact replies are not necessarly returned in requests order- doesn't not
mean that clients have to choose the FIDs. This would also work if FIDs
are choosen by the server (and even better because the client would not
have to take care of the order).
So unless Russ is right and that the fact FIDS are choosen by the client has
been decided arbitrarily ... I still have no answer to my question.
Phil;
Philippe Anel a écrit :
Ok I agree ... as long as you don't expect the replies to be returned
in the same order as the requests, requests can be pipelined.
Therefore, now it makes sense to have FIDs chosen by the client.
Thank you.
Well you may have a point, but why not
1. send: open, fid, file
2. wait for reply to 1.
3. send read, fid, args
4. send read, fid, args
5. wait for either...
6. wait for remaining?
At that point you're still pipelining, and since you're reading
presumably into separate buffers, or different locations in the same
buffer, who cares about the order?
Because all transactions are tagged ... this wouldn't break
9P. However, this doesn't work as expected.
Depends on what's expected :-)
That's why I think 9P was not designed to allow this. But
maybe I'm wrong.
It's probably designed to allow what I just said, you can sequence
some operations, but then things that don't need to be sequenced
could be pipelined.
Different servers may behave differently, 9P makes no guarantee AFAIK.
Dave
Phil;
--
- Passage Matthew 5:37:
But let your communication be, Yea, yea; Nay, nay: for whatsoever
is more than these cometh of evil.
