[9fans] read9pmsg usage

[9fans] read9pmsg usage

[Giacomo Tesio]

[-- Attachment #1: Type: text/plain, Size: 1335 bytes --]

Hi, I've a probably naive question that I can't figure out.
I've just noticed that fcall(2) states

> Read9pmsg calls read(2) multiple times, if necessary, to
> read an entire 9P message into buf.  The return value is 0
> for end of file, or -1 for error; it does not return partial
> messages.
>
>
but I've noticed that a few client does not interpret a 0 return value as a
EOF, eg

https://github.com/brho/plan9/blob/master/sys/src/cmd/usb/lib/fs.c#L604-L606
https://github.com/brho/plan9/blob/master/sys/src/cmd/usb/audio/audiofs.c#L889-L891
https://github.com/brho/plan9/blob/master/sys/src/cmd/aux/searchfs.c#L613-L615
https://github.com/brho/plan9/blob/master/sys/src/cmd/lnfs.c#L547-L551
https://github.com/brho/plan9/blob/master/sys/src/cmd/telco/telco.c#L935-L937

The comment there states that

/*
 * reading from a pipe or a network device
 * will give an error after a few eof reads.
 * however, we cannot tell the difference
 * between a zero-length read and an interrupt
 * on the processes writing to us,
 * so we wait for the error.
 */

However many other fs just handle errors and eof together, for example here:
https://github.com/brho/plan9/blob/master/sys/src/cmd/ip/ftpfs/ftpfs.c#L273-L279

I'm a bit confused about this. What's the proper use of the 0 return value?


Giacomo

[-- Attachment #2: Type: text/html, Size: 2165 bytes --]

Re: [9fans] read9pmsg usage

[erik quanstrom]

[-- Attachment #1: Type: text/html, Size: 2516 bytes --]

Re: [9fans] read9pmsg usage

[Giacomo Tesio]

[-- Attachment #1: Type: text/plain, Size: 303 bytes --]

2015-08-10 16:22 GMT+02:00 erik quanstrom <quanstro@quanstro.net>:

> on plan 9 systems 0 writes are not discarded.
>
Interesting! Is this "by design"?
And what is the intended usage of 0 writes?

BTW, so fcall(2) is misleading, a 0 read can not be used to identify an
EOF, right?


Giacomo

[-- Attachment #2: Type: text/html, Size: 658 bytes --]

Re: [9fans] read9pmsg usage

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 1365 bytes --]

Zero conventionally means end-of-file, but record boundaries are preserved
on capable streams, so if a writer writes zero, the reader reads zero.

Having said that, I think the comment is wrong, and read9pmsg returning
zero should be interpreted as the end of the (9p) stream.
In most cases, the writer will be devmnt, locally or remote, and that
should not be generating zero writes (empty records).

Funnily enough, I was just going to ask about this myself, specifically
whether anyone had seen this case,
since I noticed yesterday than 9front had changed several read9pmsg calls
to do the same thing, which I was curious about.
After all, if an empty record is somehow commonly occurring in a 9p stream,
and should be ignored, you'd think read9pmsg
would be the place to do that.  I don't, however, think anyone should be
ignoring the zero return, and if something is generating
spurious empty records, that writer should be fixed not to do it.


On 10 August 2015 at 15:35, Giacomo Tesio <giacomo@tesio.it> wrote:

> 2015-08-10 16:22 GMT+02:00 erik quanstrom <quanstro@quanstro.net>:
>
>> on plan 9 systems 0 writes are not discarded.
>>
> Interesting! Is this "by design"?
> And what is the intended usage of 0 writes?
>
> BTW, so fcall(2) is misleading, a 0 read can not be used to identify an
> EOF, right?
>
>
> Giacomo
>

[-- Attachment #2: Type: text/html, Size: 2248 bytes --]

Re: [9fans] read9pmsg usage

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 571 bytes --]

As a further historical note, originally 9P required a stream that preseved
record boundaries, and the reliable datagram protocol IL/IP and pipes did
that. Once TCP/IP was used, there was some fussing needed to work out where
the records were, so the revision 9P2000 added a size and the stream didn't
need to preserve boundaries itself. As an aside, John Day in his
interesting Patterns in Network Architecture (http://goo.gl/4WKu1r)
discusses whether protocols should preserve record boundaries, and
concludes that they should (assuming I remember correctly!).

[-- Attachment #2: Type: text/html, Size: 655 bytes --]

Re: [9fans] read9pmsg usage

[Giacomo Tesio]

[-- Attachment #1: Type: text/plain, Size: 493 bytes --]

2015-08-10 16:54 GMT+02:00 Charles Forsyth <charles.forsyth@gmail.com>:

> Zero conventionally means end-of-file, but record boundaries are preserved
> on capable streams, so if a writer writes zero, the reader reads zero.
>

However this two requirements do not seem reconcilable.

Zero can either mean EOF or "I'm alive but boring".

I can't see how a reliable communication (a cpu connection for example) can
survive this mismatch.
I'm probably missing something.


Giacomo

[-- Attachment #2: Type: text/html, Size: 988 bytes --]

Re: [9fans] read9pmsg usage

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 976 bytes --]

On 10 August 2015 at 21:17, Giacomo Tesio <giacomo@tesio.it> wrote:

> Zero can either mean EOF or "I'm alive but boring".
>
>
I can't see how a reliable communication (a cpu connection for example) can
> survive this mismatch.
> I'm probably missing something.
>

A specialised reader and writer can always agree that it means something
else in a particular case,
but the general convention is that zero (empty record) means you've hit the
end of a sequence of records (if write boundaries are preserved)
or the end of a sequence of bytes (if write boundaries are not preserved),
and thus end of file.
In other words, the interpretation is the traditional one from UNIX and
other systems.

It isn't intended as a general "keep-alive" mechanism. That's why the
read9pmsg case is odd,
and why I think the comment and code are wrong.

You could for instance use it to send several distinct byte streams through
a pipe, but only to a specialised reader.

[-- Attachment #2: Type: text/html, Size: 1820 bytes --]

Re: [9fans] read9pmsg usage

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 732 bytes --]

On 10 August 2015 at 15:11, Giacomo Tesio <giacomo@tesio.it> wrote:

> /*
>  * reading from a pipe or a network device
>  * will give an error after a few eof reads.
>  * however, we cannot tell the difference
>  * between a zero-length read and an interrupt
>  * on the processes writing to us,
>  * so we wait for the error.
>  */
>
>
it's doubly odd, because there's no reason for an interrupted writer to go
to the lengths of writing an empty record as a consequence of being
interrupted. it will waserror out in the writer, so why should an empty
Block end up on the underlying Queue?
In fact, an interrupted writer in devmnt will start the flush(5) protocol,
so it will be writing Tflush, not empty records.

[-- Attachment #2: Type: text/html, Size: 1043 bytes --]

Re: [9fans] read9pmsg usage

[Giacomo Tesio]

[-- Attachment #1: Type: text/plain, Size: 1586 bytes --]

2015-08-11 17:48 GMT+02:00 Charles Forsyth <charles.forsyth@gmail.com>:

>
> On 10 August 2015 at 15:11, Giacomo Tesio <giacomo@tesio.it> wrote:
>
>> /*
>>  * reading from a pipe or a network device
>>  * will give an error after a few eof reads.
>>  * however, we cannot tell the difference
>>  * between a zero-length read and an interrupt
>>  * on the processes writing to us,
>>  * so we wait for the error.
>>  */
>>
>>
> it's doubly odd, because there's no reason for an interrupted writer to go
> to the lengths of writing an empty record as a consequence of being
> interrupted. it will waserror out in the writer, so why should an empty
> Block end up on the underlying Queue?
>

Ah, if only git existed when that comment was written! :-D

When I read that comment I though of a remote user space writer, whose
kernel (an old plan9 version?) on process interrupt gracefully send EOFs to
all chan open for write.

However I wasn't able to find anything concrete prove of this behavior in
the codebase (but maybe I looked at the wrong places)


> In fact, an interrupted writer in devmnt will start the flush(5) protocol,
> so it will be writing Tflush, not empty records.
>

This is interesting too: I thought that Tflush were for requests that had
not yet been completed. But the interrupted writer could be just waiting. I
mean the chan is open, but its last Twrite has already been replied with a
Rwrite.

In this case, sending a EOF on behalf of a process could have sense... or
not? Probably depends on the interrupt.


Giacomo

[-- Attachment #2: Type: text/html, Size: 2483 bytes --]

Re: [9fans] read9pmsg usage

[David du Colombier]

> Ah, if only git existed when that comment was written! :-D

This comment is indeed pretty old. It was already present
in the Second Edition.

--
David du Colombier

Re: [9fans] read9pmsg usage

[Giacomo Tesio]

[-- Attachment #1: Type: text/plain, Size: 583 bytes --]

2015-08-12 9:25 GMT+02:00 David du Colombier <0intro@gmail.com>:

> This comment is indeed pretty old. It was already present
> in the Second Edition.
>

So that check is based on pre 9p2000 code? If so, Charles have probably
explained it:

2015-08-10 17:40 GMT+02:00 Charles Forsyth <charles.forsyth@gmail.com>:

> As a further historical note, originally 9P required a stream that
> preseved record boundaries, and the reliable datagram protocol IL/IP and
> pipes did that.
>

So, seem that ignoring zeros is simply wrong. A residual from the past...


Giacomo

[-- Attachment #2: Type: text/html, Size: 1170 bytes --]

Re: [9fans] read9pmsg usage

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 321 bytes --]

On 12 August 2015 at 10:18, Giacomo Tesio <giacomo@tesio.it> wrote:

> So, seem that ignoring zeros is simply wrong. A residual from the past...


There doesn't seem to be any justification for it now, whatever the
original problem.
Even if there were something, I'd fix that instead of ignoring the
convention.

[-- Attachment #2: Type: text/html, Size: 637 bytes --]