From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <21717812-8eaa-40ed-b993-9c91287e8445@email.android.com> Date: Mon, 10 Aug 2015 15:54:39 +0100 Message-ID: From: Charles Forsyth To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=e89a8f64720f3a87cd051cf62a12 Subject: Re: [9fans] read9pmsg usage Topicbox-Message-UUID: 65a66af2-ead9-11e9-9d60-3106f5b1d025 --e89a8f64720f3a87cd051cf62a12 Content-Type: text/plain; charset=UTF-8 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 wrote: > 2015-08-10 16:22 GMT+02:00 erik quanstrom : > >> 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 > --e89a8f64720f3a87cd051cf62a12 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Zero conventionally means end-of-file, but record boundari= es are preserved on capable streams, so if a writer writes zero, the reader= reads zero.

Having said that, I think the comment is wr= ong, 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 mys= elf, specifically whether anyone had seen this case,
since I noti= ced yesterday than 9front had changed several read9pmsg calls to do the sam= e 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&#= 39;d think read9pmsg
would be the place to do that.=C2=A0 I don&#= 39;t, however, think anyone should be ignoring the zero return, and if some= thing is generating
spurious empty records, that writer should be= fixed not to do it.

<= br>
On 10 August 2015 at 15:35, Giacomo Tesio <gi= acomo@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 i= s the intended usage of 0 writes?

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


Giacomo

--e89a8f64720f3a87cd051cf62a12--