On Feb 17, Michael Bell wrote: > If a Linux system runs with a high system load then it can happen > that "read" returns a 0 but it is no EOF. The perldocumentation > "man perlfunc" includes the statement that a zero only happens at > EOF. We tested the same situation with a Solaris system which > does not produce this error. > > We start studying the POSIX documentation and found a small > change. In the early years the interpretation of read was that > a not positive number signals an error or EOF because read is > usually blocking I/O. The actual POSIX documentation only > requires a non-negative return value if anything is ok. EOF is > not ok and must be tested seperately. > > Nevertheless it looks like the implementations use the not so > restrictive POSIX specs for different interpretations. Linux can > return a zero under high load and this is no eof. Solaris > implements full blocking I/O and only returns positive numbers > of characters. They never return zero characters as successful > read operation. > > There are two possible solution. First you can simply change the > documentation but this is not more than declaring a bug as a > feature. The second solution is to read until a positive number > of characters was returned from the read syscall. Thanks for pointing out the lack of clarity. However, note that Perl's read() is documented _not_ to be the libc read() -- one must use Perl's sysread() to expect POSIX semantics. I favor letting read() return 0 bytes when 0 bytes are available, as long as the filehandle is non-blocking. Thus, I would recommend changing the documentation rather than the implementation. - Kurt