Re: zpty non-functional?

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Aug 25,  7:59pm, Peter Stephenson wrote:
}
} I added a test, but if instead of using the pipe I add a string as
} arguments to zpty -w it usually fails:  I get some of the string
} followed by the whole of the string in the output.  This suggests the
} write is doing something weird.

I modified the test to use "zpty cat 'strace cat 2>file'" and to use
"zpty -w cat sample strings" instead of the pipe, then examined the
strace output.  The "cat" process always reads/writes exactly what it
is meant to, even when the test fails.

I then suspected that the problem is with "ztpy -r" not with -w.  If
I change the test to write two lines:

	print a line of text | zpty -w cat
	var=; zpty -r cat var
	zpty -w cat sample strings
	var=; zpty -r cat var

then it always succeeds.  If I swap the order so that the pipe is the
second of the two writes, then it always *fails*, repeating the same
output ("sample strings") twice, but strace still shows cat reading
and writing the correct two lines in the correct order.

Further testing by using "cat > /dev/null" shows that when "zpty -w"
is used, the pty acts as if it is in echo mode, so "zpty -r" reads
back what zpty -w wrote.  In the pipe mode, for some reason, this does
not happen.  ptywrite() is called just once in either case, and I
confirmed that ptysettyinfo() is being called at pty setup.

If I put in some debugging statements such as zwarn calls in ptywrite,
then I sometimes get only partial echo behavior, e.g., I'll get back
"samplesample strings" and then "a line of text".

I also tried adding a pid > 0 branch to the zfork conditional in which
close(slave) is done [which seems like the right thing anyway] but that
did not fix the behavior, although I thought briefly that it changed it.

Finally I tried putting a "sleep 1" in the test before the first write
to the pty.  This makes it succeed 100% of the time, regardless of the
order of the pipe or direct write.

This leads me to conclude that it's a race condition:  The master writer
may read back what it wrote, up until the point that there is a process
on the slave side consuming it instead.

Whether this means we want to copy the synch[] pipe hack from exec.c to
prevent zpty from returning before the child process is running, or just
document the possible race, I will leave up to consensus (or PWS).