Keeping atomicity of write() through ssh

[Peter Stuge]

Valentin LAB wrote:
> even if each PipeView are in separate processes, the write() command
> is garanteed to be atomic

That'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