From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <461C45A4.3060909@tecmav.com>
Date: Wed, 11 Apr 2007 04:19:16 +0200
From: Adriano Verardo <a.verardo@tecmav.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.3) Gecko/20040910
MIME-Version: 1.0
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] 9P2000 and p9p
References: <20070410225039.B7AA01E8C1C@holo.morphisms.net>
In-Reply-To: <20070410225039.B7AA01E8C1C@holo.morphisms.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 444756b6-ead2-11e9-9d60-3106f5b1d025

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