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 21:33:13 +0100 Message-ID: From: Charles Forsyth To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=e89a8f839ebb08ba24051cfae5a4 Subject: Re: [9fans] read9pmsg usage Topicbox-Message-UUID: 65beb26a-ead9-11e9-9d60-3106f5b1d025 --e89a8f839ebb08ba24051cfae5a4 Content-Type: text/plain; charset=UTF-8 On 10 August 2015 at 21:17, Giacomo Tesio 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. --e89a8f839ebb08ba24051cfae5a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 10 August 2015 at 21:17, Giacomo Tesio <giacomo@tesio.it> = wrote:
Zero ca= n either mean EOF or "I'm alive but boring".
=C2=A0
<= /div>
I can't see how a reliable communicatio= n (a cpu connection for example) can survive this mismatch.
I'm pro= bably missing something.

A specialised = reader and writer can always agree that it means something else in a partic= ular case,
but the general convention is th= at zero (empty record) means you've hit the end of a sequence of record= s (if write boundaries are preserved)
or th= e end of a sequence of bytes (if write boundaries are not preserved), and t= hus end of file.
In other words, the interp= retation is the traditional one from UNIX and other systems.

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

You could for instance use it to send several distinct by= te streams through a pipe, but only to a specialised reader.
--e89a8f839ebb08ba24051cfae5a4--