develooper Front page | perl.perl5.porters | Postings from February 2004

Re: [perl #26787] read reports wrong eof under high system load

Thread Previous | Thread Next
Dave Mitchell
February 19, 2004 07:16
Re: [perl #26787] read reports wrong eof under high system load
Message ID:
On Thu, Feb 19, 2004 at 02:34:03PM +0000, Ton Hospel wrote:
> In article <>,
> 	Michael Bell <> writes:
> > (Ton Hospel) via RT wrote:
> >> In article <>,
> >> 	Michael Bell (via RT) <> writes:
> >>
> >>>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.
> >>>
> >>
> >> Personally I'd rather see this reported as a linux bug. Do
> >> you have code to reproduce this ?
> >
> > No, I have no small script to do this. We found this problem during
> > testing a batch system for a PKI (OpenCA). The problem only happens if
> > you have more than 90 percent total system load.
> >
> > I don't think that it is a Linux bug because this behaviour is compliant
> > to the POSIX specs. I think that Perl is not aware of the latest POSIX
> > specs (blocking read can return zero characters and this is correct).
> > BTW I think that the real bug is in the POSIX specs because there is not
> > explicitly written that a zero always signals EOF if it is a blocking
> > read on a regular file. I like the Solaris behaviour much more than the
> > Linux one's.
> My reading only mentions a rather obscure "If any portion of a regular
> file prior to the end-of-file has not been written, read() returns bytes
> with value 0."
> Apart form that this seems appropiate:
> "If O_NONBLOCK is clear, read() will block the calling thread until
> some data becomes available"
> and
> "If the starting position is at or after the end-of-file, 0 will be returned."

From reading the read(2) manpage (on RH 7.2 and Fedora Core 1),
it will onlt ever return 0 on EOF. For a non-blocking filehandle, this
is handled by EAGAIN, or if interrupted by a signal before any bytes can be
read, then by EINTR. If Linux *is* returning 0 before EOF, then it's
disobeying its own documentation. And if POSIX does santion this
(I havn't loooked), then POSIX is broken. 

Does the OP have any actual proof that the Linux read() system
call ever returns 0 in a situation where it isn't EOF (as opposed to say
where the file is still being actively written to, so it was briefly at
EOF but isn't now)?


"I do not resent critisism, even when, for the sake of emphasis,
it parts for the time with reality".
    -- Winston Churchill, House of Commons, 22nd Jan 1941.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About