[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: hangup in close(2) after posix_openpt(3)
> >> That seems like a bug of sorts, but I think it's a symptom of PR
> >> 17171;
> > [...] 12534 [...]
> Possibly, but, don't forget, both 17171 and 12534 are about unread
> slave->master data. This hang is about unread master->slave data (or,
> at least, that's what it looks like to me).
The report said the problem went away when they disabled echo, and the
echo would be slave->master data. Also, I have verified that the test
program in the report hangs on 7.0, but continues after a five-second
timeout on -current.
I did notice one difference between the present report and
17171/12534: in the present report, the hang happens during an
explicit close() rather than when the tty is implicitly closed during
process exit. But the two cases are similar enough that the fix for
17171/12534 works here, too (for values of "works" where a five-second
delay is acceptable).
Now, I think the argument could be made that the 7.0 behavior is actually
correct, that the close() *should* block (interruptibly) until the
last echoed character has been read by the master, and that the -current
behavior is incorrect because it will lead to data loss when the master
does not read the last data output by the slave within five seconds of
the slave closing the pty.
In the case of an exiting process we don't have much of a choice - we
need something like the -current 17171/12534 fix because if the output
data aren't discarded, the slave process will never die. But in the
case of an explicit close(), we don't have that problem - the process
can still be killed by a signal.
So, somewhat ironically, it seems you were saying the reported
behavior is a bug but probably hasn't been fixed, and I'm saying it
has been fixed but probably isn't a bug :)
Andreas Gustafsson, gson%gson.org@localhost
Main Index |
Thread Index |