Russ Cox wrote:
As Charles pointed out, what you describe is in fact
the behavior of fread(3) (from stdio) but is not the
behavior of the underlying read(2) system call,
even on Unix. An EOD flag can't work without
either (a) changing the system call interface or
(b) having some kind of lease so that the EOD can
be invalidated when more data comes in between
the first read and the second read (which you
propose the operating system should answer without
reference to the 9P server).
It depends on the time between the two read.
If they were within a few time slices the second
one could return 0 without Tread to to the file server.
The data coming in between the first and second
read is (IMO) a false problem. All would go as the new data
were arrived just after the second (true) read to the file server.
The extra fids you see when mounting under Linux
don't grow without bound.
With an infinite loop of "lc /n/adri" the max is 8630 for
a FreeBSD p9p session. Ok (!?) for RTEMS|VxWorks|eCos|... on x86, not
for a mCtrl.
Clients under Plan9 would be "the" solution, but sometimes Lunix
is a must.
Adriano
