From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <461C0C31.80000@tecmav.com>
Date: Wed, 11 Apr 2007 00:14:09 +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: <20070410182940.6EC861E8C3B@holo.morphisms.net>
In-Reply-To: <20070410182940.6EC861E8C3B@holo.morphisms.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 43700882-ead2-11e9-9d60-3106f5b1d025

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