A tempest in a tty pot

Posted Jul 31, 2009 23:23 UTC (Fri) by alex_the_d (guest, #59935)
Parent article: A tempest in a tty pot

I'm reading http://www.opengroup.org/onlinepubs/000095399/basedefs/xb... and...

1. "Also, no matter how many bytes are requested in the read() call, at most one line shall be
returned." (in canonical mode)

2. "process to close a terminal device file shall cause any output to be sent to the device and any
input to be discarded."

I don't think the problem is in userland, neither emacs nor kdesu. Can someone comment?

A tempest in a tty pot

Posted Aug 1, 2009 10:15 UTC (Sat) by nix (subscriber, #2304) [Link] (7 responses)

The problem with Emacs, at least, is in userland. POSIX says that closing
(including, implicitly, as a result of process termination) 'shall cause
any output to be sent to the device', but it does *not* impose an ordering
on the dispatch of SIGCHLD versus a read() of those bytes. So the SIGCHLD
can arrive at any time, including while you're reading data.

Since this can happen when you're reading any data from anywhere, it seems
unfortunate that Emacs isn't looping on -EINTR in read() everywhere.

(That part of the Unix API sucks rocks. SA_RESTART should have been the
default forever, IMNSHO. Instead, we *still* can't rely on it if we want
to be portable: two of the platforms I have to write code for don't
support it, so it's still -EINTR loops everywhere...)

A tempest in a tty pot

Posted Aug 2, 2009 15:36 UTC (Sun) by pflugstad (subscriber, #224) [Link] (2 responses)

Good explanation, thanks!

Shouldn't emacs really be looping until it get EOF/close on the pipe (which would implicitly loop on -EINTR)? Unfortunatley, I don't have my copy of Stevens handy... it's been too long since I messed with tty/pty stuff.

Depending on the ordering of SIGCHLD and reading data from the pipe seems quite fragile to me. I'm surprised something as mature/old as Emacs depends on it.

A tempest in a tty pot

Posted Aug 2, 2009 19:58 UTC (Sun) by nix (subscriber, #2304) [Link]

Not exactly, It should loop as long as it gets any data, until it
gets -EOF/close on the pipe or gets *any error other than -EINTR*.

Otherwise you're going to loop forever if there's an error.

A tempest in a tty pot

Posted Aug 3, 2009 13:02 UTC (Mon) by clugstj (subscriber, #4020) [Link]

Anything as "old/mature" as Emacs probably has other bad assumptions lurking in it. It should come as no surprise.

Assuming an order between read() and signal reception is ALWAYS a bad idea.

A tempest in a tty pot

Posted Aug 3, 2009 3:49 UTC (Mon) by alex_the_d (guest, #59935) [Link] (3 responses)

I'm pretty sure 'a read() of those bytes' (by emacs) is one part of a proccess of sending output to the
device. Emacs is 'the device' here and terminal line can not be closed and disconnected until all data
is sent. There should be no chance for the application to exit until the output is 'sent to the device'
hence no chance for the kernel to thow SIGCHLD.

It's not a pipe nor stream, it's an intaractive tty/pty.

A tempest in a tty pot

Posted Aug 3, 2009 22:30 UTC (Mon) by nix (subscriber, #2304) [Link] (2 responses)

The process of sending the data through a pty or tty is desynchronized
from the state of the process doing the sending. If a process sends data,
then exits, it can be gone (and SIGCHLD fired) *long* before the buffers
are flushed to the receiving app. This has always been true (I first
remember noticing it on SunOS 4, but it was old even then) and is
essential for good performance over slower lines or under high load.

(Emacs is not the device. The device and buffering for it are kernel
entities. Emacs is merely the entity on the *master side* of the device.)

A tempest in a tty pot

Posted Aug 4, 2009 8:46 UTC (Tue) by alex_the_d (guest, #59935) [Link] (1 responses)

> The device and buffering for it are kernel entities.

No, 'kernel entities' are 'device driver(s)'. THE device is that beige box on the table or a piece of
code emulating it (emacs).

A tempest in a tty pot

Posted Aug 4, 2009 21:06 UTC (Tue) by nix (subscriber, #2304) [Link]

The fact remains that POSIX does not require process exit signal / TTY
flush synchronization, and I know of no Unix that ensures that these
things are synchronized. Your musings about what constitutes 'the device'
are thus not terribly relevant. The system simply does not work the way
you would like it to (and the way some app authors assume).