Russ Cox wrote:
Your argument assumes no correlation between
the reads and the writes.
If they are performed by different machines ...
Maybe a test program does
write
read
write
read
Then you will fail the second read incorrectly.
This is a different situation. In the example above read an write are
done by one program and are from/to the same file server.
The kernel knows where/when/what it reads/writes.
A task "exec in kernel" (EMT also in Plan9 ? I don't know)
one syscall at a time. To avoid the problem, the read after
a write must be performed ignoring the EOD. The second read in
a read-read seq must be short-circuited when the EOD is active.
Each read sets the EOD (or time window) to guide the kernel for the next
read.
Or maybe correlations between operations on different
machines will yield the same case.
There is no correlation between read and write ops executed on different
machines to the same file server, wherever it is running on. The second
zero-data read says that NOW there is no other data to read from that
server. Thats the same info fread(3) would have from a nbyte(or 0) read
+ EOD, apart from a slightly difference in the "NOW" absolute time.
Where is the difference ? I think I have a read miss only when an
asynchronous read returns 0 data AND I'm sure that there is something
to read. If I'm not sure, is as if there were (certainly) nothing to
read. In other words, the data that is available on the server just a
pico-sec after the second zero read of the normal cycle is lost or got
with some delay ? If it is lost, the solution is to delay the second
read ? 1 psec ? 1 msec ...
... very academic discussion I'm not able to argue in english as I could
(attempt to) do in italian :-(
Of course I'm not thinking to modify the kernel. Instead I think that
the EOD flag in the Rread packets could be useful for specialised appls
with a weak interaction with Plan9 (or other 9P speaking higher level
box), which should ignore it at all.
To have only one protocol for low<->low and low<->high levels
communications.
Adriano
