develooper Front page | perl.perl5.porters | Postings from September 2012

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

Thread Previous | Thread Next
From:
James E Keenan via RT
Date:
September 29, 2012 18:57
Subject:
[perl #26787] read reports wrong eof under high system load
Message ID:
rt-3.6.HEAD-11172-1348970236-339.26787-15-0@perl.org
On Thu Feb 19 07:17:28 2004, davem@fdisolutions.com wrote:
> On Thu, Feb 19, 2004 at 02:34:03PM +0000, Ton Hospel wrote:
> > In article <40346D81.8090905@cms.hu-berlin.de>,
> > 	Michael Bell <michael.bell@cms.hu-berlin.de> writes:
> > > (Ton Hospel) via RT wrote:
> > >> In article <rt-3.0.8-26787-78336.2.2498005290219@perl.org>,
> > >> 	Michael Bell (via RT) <perlbug-followup@perl.org> 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)?
> 
> Dave.
> 

Dave, do you believe that there is still a problem that needs addressing
here?

Thank you very much.
Jim Keenan


---
via perlbug:  queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=26787

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About