Keeping atomicity of write() through ssh

[Valentin LAB]

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