Front page | perl.perl5.porters |
Postings from February 2004
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