Re: [9fans] read9pmsg usage
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
2015-08-12 9:25 GMT+02:00 David du Colombier 0in...@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.fors...@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
Re: [9fans] read9pmsg usage
On 12 August 2015 at 10:18, Giacomo Tesio giac...@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.
Re: [9fans] read9pmsg usage
2015-08-11 17:48 GMT+02:00 Charles Forsyth charles.fors...@gmail.com: On 10 August 2015 at 15:11, Giacomo Tesio giac...@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
Re: [9fans] read9pmsg usage
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!).
Re: [9fans] read9pmsg usage
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 giac...@tesio.it wrote: 2015-08-10 16:22 GMT+02:00 erik quanstrom quans...@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
Re: [9fans] read9pmsg usage
2015-08-10 16:54 GMT+02:00 Charles Forsyth charles.fors...@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
Re: [9fans] read9pmsg usage
On 10 August 2015 at 21:17, Giacomo Tesio giac...@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.
Re: [9fans] read9pmsg usage
on plan 9 systems 0 writes are not discarded. - erik On Aug 10, 2015 7:11 AM, Giacomo Tesio giac...@tesio.it wrote:Hi, Ive a probably naive question that I cant figure out.Ive just noticed that fcall(2) statesRead9pmsg 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 Ive noticed that a few client does not interpret a 0 return value as a EOF, eghttps://github.com/brho/plan9/blob/master/sys/src/cmd/usb/lib/fs.c#L604-L606https://github.com/brho/plan9/blob/master/sys/src/cmd/usb/audio/audiofs.c#L889-L891https://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-L551https://github.com/brho/plan9/blob/master/sys/src/cmd/telco/telco.c#L935-L937The 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-L279Im a bit confused about this. Whats the proper use of the 0 return value?Giacomo
