9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Adriano Verardo <a.verardo@tecmav.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] 9P2000 and p9p
Date: Wed, 11 Apr 2007 04:19:16 +0200	[thread overview]
Message-ID: <461C45A4.3060909@tecmav.com> (raw)
In-Reply-To: <20070410225039.B7AA01E8C1C@holo.morphisms.net>

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






  reply	other threads:[~2007-04-11  2:19 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-10 17:12 Adriano Verardo
2007-04-10 17:39 ` Charles Forsyth
2007-04-10 18:14   ` Adriano Verardo
2007-04-10 19:33     ` C H Forsyth
2007-04-10 21:28       ` Adriano Verardo
2007-04-10 18:29 ` Russ Cox
2007-04-10 22:14   ` Adriano Verardo
2007-04-10 22:38     ` Charles Forsyth
2007-04-10 22:50     ` Russ Cox
2007-04-11  2:19       ` Adriano Verardo [this message]
2007-04-11  2:55         ` erik quanstrom
2007-04-11  3:10         ` Russ Cox
2007-04-11  6:58           ` Bruce Ellis
2007-04-11  8:20             ` Charles Forsyth
2007-04-11 15:38               ` ron minnich
2007-04-11  2:50 ` Kris Maglione

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=461C45A4.3060909@tecmav.com \
    --to=a.verardo@tecmav.com \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).