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