From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 From: Giacomo Tesio Date: Mon, 15 May 2017 12:05:47 +0200 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>, 9front@9front.org Content-Type: text/plain; charset="UTF-8" Subject: [9fans] Blocking on write Topicbox-Message-UUID: bcfe2556-ead9-11e9-9d60-3106f5b1d025 Hi, to write a test I'm looking for an easy way to have a write() blocking forever. Is there any fs/device in Plan9 that can easily provide such behaviour? Giacomo From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: From: Charles Forsyth Date: Mon, 15 May 2017 11:32:52 +0100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="001a114c84a0daaea3054f8d9326" Cc: 9front@9front.org Subject: Re: [9fans] Blocking on write Topicbox-Message-UUID: bd0d4d56-ead9-11e9-9d60-3106f5b1d025 --001a114c84a0daaea3054f8d9326 Content-Type: text/plain; charset="UTF-8" On 15 May 2017 at 11:05, Giacomo Tesio 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). --001a114c84a0daaea3054f8d9326 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On 15 May 2017 at 11:05, Giacomo Tesio <giacomo@tesio.it> wro= te:
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 32= k on small ones).
--001a114c84a0daaea3054f8d9326-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: From: Giacomo Tesio Date: Mon, 15 May 2017 15:36:32 +0200 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset="UTF-8" Cc: 9front@9front.org Subject: Re: [9fans] Blocking on write Topicbox-Message-UUID: bd36c5aa-ead9-11e9-9d60-3106f5b1d025 Thanks Charles! Giacomo 2017-05-15 12:32 GMT+02:00 Charles Forsyth : > > On 15 May 2017 at 11:05, Giacomo Tesio 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). From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: From: Giacomo Tesio Date: Mon, 15 May 2017 17:46:16 +0200 Message-ID: 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 : > Thanks Charles! > > > Giacomo > > 2017-05-15 12:32 GMT+02:00 Charles Forsyth : >> >> On 15 May 2017 at 11:05, Giacomo Tesio 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-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: From: Charles Forsyth Date: Mon, 15 May 2017 17:12:22 +0100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="f403045f26880821fd054f9252e8" Cc: 9front@9front.org Subject: Re: [9fans] Blocking on write Topicbox-Message-UUID: bd8617c2-ead9-11e9-9d60-3106f5b1d025 --f403045f26880821fd054f9252e8 Content-Type: text/plain; charset="UTF-8" On 15 May 2017 at 16:46, Giacomo Tesio wrote: > Shouldn't the waserror code check that the queue has been actually closed? Either that or check errstr against Ehungup, since that's the exact error it incurred. The latter has the advantage of not obscuring a different error if the pipe is closed between the write and waserror, but with pipes there's not much except interrupt, I suppose, so it seems a minor race and perhaps the qclosed check is adequate. --f403045f26880821fd054f9252e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On 15 May 2017 at 16:46, Giacomo Tesio <giacomo@tesio.it> wro= te:
Shouldn't the waserror code check= that the queue has been actually closed?

Either that= or check errstr against Ehungup, since that's the exact error it incur= red.
The latter has the advantage of not ob= scuring a different error if the pipe is closed
between the write and waserror, but with pipes there's not much ex= cept interrupt, I suppose,
so it seems a mi= nor race and perhaps the qclosed check is adequate.
--f403045f26880821fd054f9252e8-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: From: Giacomo Tesio Date: Wed, 17 May 2017 17:46:31 +0200 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="001a113fe4e83c851a054fba3141" Cc: 9front@9front.org Subject: Re: [9fans] Blocking on write Topicbox-Message-UUID: bdedb152-ead9-11e9-9d60-3106f5b1d025 --001a113fe4e83c851a054fba3141 Content-Type: text/plain; charset="UTF-8" In Jehanne, I decided to test both: if the queue is not closed there's no need to check up->errstr. Thanks for your help! Giacomo 2017-05-15 18:12 GMT+02:00 Charles Forsyth : > > On 15 May 2017 at 16:46, Giacomo Tesio wrote: > >> Shouldn't the waserror code check that the queue has been actually closed? > > > Either that or check errstr against Ehungup, since that's the exact error > it incurred. > The latter has the advantage of not obscuring a different error if the > pipe is closed > between the write and waserror, but with pipes there's not much except > interrupt, I suppose, > so it seems a minor race and perhaps the qclosed check is adequate. > --001a113fe4e83c851a054fba3141 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In Jehanne, I decided to test both: if the queue= is not closed there's no need to check up->errstr.

Tha= nks for your help!


Giacomo

2017-05-15 18:12 GMT+02:00 Charles Fors= yth <charles.forsyth@gmail.com>:

On 15 May 2017 at 16:46, Giacomo Tesio <gia= como@tesio.it> wrote:
Shoul= dn't the waserror code check that the queue has been actually closed?

Either that or check errstr against Ehungup, si= nce that's the exact error it incurred.
The latter has the advantage of not obscuring a different error if the pip= e is closed
between the write and waserror,= but with pipes there's not much except interrupt, I suppose,
so it seems a minor race and perhaps the qclosed che= ck is adequate.

--001a113fe4e83c851a054fba3141--