From mboxrd@z Thu Jan  1 00:00:00 1970
MIME-Version: 1.0
In-Reply-To: <CAHL7psHZ8mCyy4=bcPOMePg3t-b8-BO5pKaWbDQsN5OFL474Mw@mail.gmail.com>
References: <CAHL7psHN3PZieDz0UiNoYFzeuxqV-mVNT_3qWjirOZm1xBrZ-Q@mail.gmail.com>
	<CAOw7k5h4hbwv1CvDr3Mb=6+mifnG3CGgAaZ36G--vtGwLMMvNA@mail.gmail.com>
	<CAHL7psHZ8mCyy4=bcPOMePg3t-b8-BO5pKaWbDQsN5OFL474Mw@mail.gmail.com>
From: Giacomo Tesio <giacomo@tesio.it>
Date: Mon, 15 May 2017 17:46:16 +0200
Message-ID: <CAHL7psH-aOtzJk5o8r-ROFaQb3MzRi8HcJsd8ZToQCpF5yrcBQ@mail.gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Content-Type: multipart/mixed; boundary="001a113fe4e8b07258054f91f4ac"
Cc: 9front@9front.org
Subject: Re: [9fans] Blocking on write
Topicbox-Message-UUID: bd7170e2-ead9-11e9-9d60-3106f5b1d025

--001a113fe4e8b07258054f91f4ac
Content-Type: text/plain; charset="UTF-8"

I've just noticed a strange behaviour in devpipe that occurs on both
9front and Plan 9.

When the write blocks, if a note interrupt the process, the waserror
in pipewrite and pipebwrite will post another note that says "sys:
write on a closed pipe ..."

However the pipe is actually open, and still works, as you can see in
the attached test.

Shouldn't the waserror code check that the queue has been actually closed?


Giacomo

2017-05-15 15:36 GMT+02:00 Giacomo Tesio <giacomo@tesio.it>:
> Thanks Charles!
>
>
> Giacomo
>
> 2017-05-15 12:32 GMT+02:00 Charles Forsyth <charles.forsyth@gmail.com>:
>>
>> On 15 May 2017 at 11:05, Giacomo Tesio <giacomo@tesio.it> wrote:
>>>
>>> Is there any fs/device in Plan9 that can easily provide such behaviour?
>>
>>
>> Bind #| to a name and fill up one of the data files (blocks at 256k on my
>> system, might be 32k on small ones).

--001a113fe4e8b07258054f91f4ac
Content-Type: text/x-csrc; charset="US-ASCII"; name="writeBlock.c"
Content-Disposition: attachment; filename="writeBlock.c"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_j2qaq9ag0

I2luY2x1ZGUgPHUuaD4KI2luY2x1ZGUgPGxpYmMuaD4KCmludAp3cml0ZVRpbGxCbG9jayhpbnQg
ZmQpCnsKCWludCBpID0gMDsKCWNoYXIgYnVmWzEwMjRdOwoJbWVtc2V0KGJ1ZiwgMSwgc2l6ZW9m
KGJ1ZikpOwoJd2hpbGUoaSA8IDMwMCl7CgkJaWYod3JpdGUoZmQsIGJ1Ziwgc2l6ZW9mKGJ1Zikp
IDwgMCkKCQkJYnJlYWs7CgkJcHJpbnQoIiVkXG4iLGkpOwoJCSsraTsKCX0KCXJldHVybiBpOwp9
CgppbnQKY29udGludWVPbkFsYXJtKHZvaWQgKnYsIGNoYXIgKnMpCnsKCWlmKHN0cm5jbXAocywg
ImFsYXJtIiwgNSkgPT0gMCkKCQlyZXR1cm4gMTsKCWlmKHN0cm5jbXAocywgInN5czogd3JpdGUg
b24gY2xvc2VkIHBpcGUiLCAyNSkgPT0gMCkKCQlyZXR1cm4gMTsKCXJldHVybiAwOwp9Cgp2b2lk
Cm1haW4odm9pZCkKewoJaW50IGZkc1syXSwgcmVzOwoJY2hhciBidWZbMTAyNF07CgoJcGlwZShm
ZHMpOwoKCWF0bm90aWZ5KGNvbnRpbnVlT25BbGFybSwgMSk7CgoJYWxhcm0oMTAwMDApOwoJcmVz
ID0gd3JpdGVUaWxsQmxvY2soZmRzWzBdKTsKCglpZihyZXMgPCAyNTYpewoJCXdoaWxlKHJlcyA+
IDEpewoJCQlyZWFkKGZkc1sxXSwgYnVmLCBzaXplb2YoYnVmKSk7CgkJCS0tcmVzOwoJCX0KCQlp
Zih3cml0ZShmZHNbMF0sIGJ1Ziwgc2l6ZW9mKGJ1ZikpIDwgMCl7CgkJCXByaW50KCJGQUlMOiBj
YW4ndCB3cml0ZSBhZnRlciByZWFkczogJXJcbiIpOwoJCQlleGl0cygiRkFJTCIpOwoJCX0KCQlw
cmludCgiUEFTU1xuIik7CgkJZXhpdHMobmlsKTsKCX1lbHNlewoJCXByaW50KCJGQUlMOiB3cml0
dGVuICVkIGtiXG4iLCByZXMpOwoJCWV4aXRzKCJGQUlMIik7Cgl9CgkKfQo=
--001a113fe4e8b07258054f91f4ac--