[9fans] Blocking on write

[9fans] Blocking on write

[Giacomo Tesio]

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

Re: [9fans] Blocking on write

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 260 bytes --]

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).

[-- Attachment #2: Type: text/html, Size: 540 bytes --]

Re: [9fans] Blocking on write

[Giacomo Tesio]

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).

Re: [9fans] Blocking on write

[Giacomo Tesio]

[-- Attachment #1: Type: text/plain, Size: 903 bytes --]

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).

[-- Attachment #2: writeBlock.c --]
[-- Type: text/x-csrc, Size: 842 bytes --]

#include <u.h>
#include <libc.h>

int
writeTillBlock(int fd)
{
	int i = 0;
	char buf[1024];
	memset(buf, 1, sizeof(buf));
	while(i < 300){
		if(write(fd, buf, sizeof(buf)) < 0)
			break;
		print("%d\n",i);
		++i;
	}
	return i;
}

int
continueOnAlarm(void *v, char *s)
{
	if(strncmp(s, "alarm", 5) == 0)
		return 1;
	if(strncmp(s, "sys: write on closed pipe", 25) == 0)
		return 1;
	return 0;
}

void
main(void)
{
	int fds[2], res;
	char buf[1024];

	pipe(fds);

	atnotify(continueOnAlarm, 1);

	alarm(10000);
	res = writeTillBlock(fds[0]);

	if(res < 256){
		while(res > 1){
			read(fds[1], buf, sizeof(buf));
			--res;
		}
		if(write(fds[0], buf, sizeof(buf)) < 0){
			print("FAIL: can't write after reads: %r\n");
			exits("FAIL");
		}
		print("PASS\n");
		exits(nil);
	}else{
		print("FAIL: written %d kb\n", res);
		exits("FAIL");
	}
	
}

Re: [9fans] Blocking on write

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 491 bytes --]

On 15 May 2017 at 16:46, Giacomo Tesio <giacomo@tesio.it> 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.

[-- Attachment #2: Type: text/html, Size: 868 bytes --]

Re: [9fans] Blocking on write

[Giacomo Tesio]

[-- Attachment #1: Type: text/plain, Size: 734 bytes --]

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 <charles.forsyth@gmail.com>:

>
> On 15 May 2017 at 16:46, Giacomo Tesio <giacomo@tesio.it> 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.
>

[-- Attachment #2: Type: text/html, Size: 1445 bytes --]