Hi, I'm sorry if this is plain dumb or was already asked, but I couldn't find any reference to this. This is about ssh acting as a real terminal. Do some of you know pipe viewer, or 'pv' ? http://www.ivarch.com/programs/pv.shtml This clever little bit of code tries to write on your terminal some stats about data going through some pipes. But there's a nasty limitation when going through ssh related to the atomicity of write() lost when going through ssh: Often you have to use multiple PipeView, and each of them have to print stats on the same line and this works with some ANSI escape code. It relies heavily on the fact that even if each PipeView are in separate processes, the write() command is garanteed to be atomic so the string sent to the fd contains the ANSI chars to relocate to the correct line, print the stats, and go back to starting position. Atomicity is important because you don't want the string being cut by other messages before its fully sent to the terminal. However, if PipeView works fine on local host, it'll break when used through ssh, and I strongly suspect ssh to break atomicity of write() on the fd. More on stdout/stderr atomicity and buffering: http://www.pixelbeat.org/programming/stdio_buffering/ So 2 questions: - Can you confirm that ssh breaks atomicity of write on stderr/stdout ? - Has this issue any chances to be fixed one day ? - Related to the last question: would you accept any patches to fix that ? My main concern is to know if there are practical important reason why the atomicity was broken, or if the current ssh current code architecture won't allow patching easily this. Thanks for your answers. -- Valentin LAB
Valentin LAB wrote:> even if each PipeView are in separate processes, the write() command > is garanteed to be atomicThat's not at all true in the general case. Quoting my man 2 write: DESCRIPTION write() writes up to count bytes from the buffer pointed buf to the file referred to by the file descriptor fd. The number of bytes written may be less than count if, for example, there is insufficient space on the underlying physical medium, or the RLIMIT_FSIZE resource limit is encountered (see setrlimit(2)), or the call was interrupted by a signal handler after having written less than count bytes. (See also pipe(7).) So relying on write() to always write either all bytes or none is, in the general case, a classical and oft-repeated application bug. Now, some file descriptor types do indeed have atomic write() behavior, but that is heavily dependent on the particular kernel driver, and unless an application ensures that a particular fd is indeed handled by a known-to-behave-that-way kernel driver, then relying on write() to be atomic is plain wrong.> Atomicity is important because you don't want the string being cut > by other messages before its fully sent to the terminal.It's possible that tty devices provide atomic write() behavior on some systems, but since they are character devices and not block devices I would actually be surprised if that is the case.> However, if PipeView works fine on local host, it'll break when used > through ssh, and I strongly suspect ssh to break atomicity of write() > on the fd.Please think again. ssh doesn't handle write() system calls - your kernel does. //Peter