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: "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: <bug-21004-131@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=21004
--- 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
something?
--
You are receiving this mail because:
You are on the CC list for the bug.