This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug stdio/21004] fread/fwrite does not handle EINTR correctly
- From: "fweimer at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Mon, 23 Jan 2017 15:33:13 +0000
- Subject: [Bug stdio/21004] fread/fwrite does not handle EINTR correctly
- Auto-submitted: auto-generated
- References: <bug-21004-131@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=21004
--- Comment #9 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Bernd Edlinger from comment #7)
> (In reply to Florian Weimer from comment #6)
> > (In reply to Bernd Edlinger from comment #5)
> > > (In reply to Florian Weimer from comment #4)
> > > > (In reply to Bernd Edlinger from comment #3)
> > > > > What exactly would break by retrying EINTR
> > > > > that is not already broken?
> > > >
> > > > Code which uses EINTR to exit a blocked fread, with a signal handler which
> > > > sets a global variable checked by the caller of fread.
> > >
> > > but this is always a race condition, if the signal does
> > > not interrupt a system call.
> >
> > In this case, the flag is still set by the signal handler.
> >
>
> Yes. But if the signal interrupts before the internal read
> the read is called and may wait infinitely, that is what
> I meant with race condition.
Ah, right, but for the ^C case, you can just hit ^C again. With the proposed
change, that possibility is gone.
--
You are receiving this mail because:
You are on the CC list for the bug.