On Sat Sep 29 18:57:17 2012, jkeenan wrote:
> 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
Can anyone help out on this?
Thank you very much.
Jim Keenan
---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=26787