This is the mail archive of the
mailing list for the glibc project.
[Bug stdio/21004] fread/fwrite does not handle EINTR correctly
- From: "bernd.edlinger at hotmail dot de" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Mon, 02 Jan 2017 10:48:52 +0000
- Subject: [Bug stdio/21004] fread/fwrite does not handle EINTR correctly
- Auto-submitted: auto-generated
- References: <firstname.lastname@example.org/bugzilla/>
--- Comment #7 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
(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.
> > Are there really programs that do that kind of programming?
> It is the standard idiom for reducing the amount of code which runs in a
> signal handler.
OTOH if they call sigaction without SA_RESTART they should know
what that means.
Bit if signal() is used it always means SA_RESTART (BSD semantic)
today, is that right, or does that depend on _BSD_SOURCE or
You are receiving this mail because:
You are on the CC list for the bug.