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
next prev parent 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).