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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
