This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug stdio/21004] fread/fwrite does not handle EINTR correctly


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]