Re: sem_wait and EINTR

[Rich Felker <dalias@libc.org>]

On Wed, Dec 05, 2018 at 10:27:16PM +0100, Ondřej Jirman wrote:
> On Wed, Dec 05, 2018 at 08:47:59PM +0100, Markus Wichmann wrote:
> > On Wed, Dec 05, 2018 at 07:16:05PM +0000, Orivej Desh wrote:
> > > Hi,
> > > 
> > > musl differs from glibc in that it does not return from sem_wait() on EINTR.
> > > This mail [1] explains that this is useful to safeguard the software that does
> > > not check sem_wait() return code. However, since glibc does return EINTR, such
> > > bugs in the open source software seem to be eventually noticed and fixed.
> > > 
> > > The musl behaviour has a disadvantage in that it makes sem_wait() difficult to
> > > interrupt (and delays the return from sem_timedwait() until the timeout), which
> > > is relied upon in particular by multithreaded fuse for breaking out of the
> > > main thread waiting loop [2]. IMHO the fuse implementation is sensible, since it
> > > looks better than the alternatives I could imagine, and I'm inclined to patch
> > > musl like this [3] to meet its expectations.
> > > 
> > > Am I missing some implications? Would you reconsider returning from sem_wait()
> > > on EINTR? Could you suggest a good fix for fuse that does not change musl?
> > > 
> > > [1] https://www.openwall.com/lists/musl/2018/02/24/3
> > > [2] https://github.com/libfuse/libfuse/blob/fuse-3.3.0/lib/fuse_loop_mt.c#L332
> > > [3] https://github.com/orivej/musl/commit/c4c38aaab4fc55c23669f7b81386b615609cc3e1
> > 
> > I wanted to suggest a reworking of libfuse to instead of waiting on a
> > semaphore maybe just wait on the actual thread. Then I read the source
> > of pthread_join() and noticed that it, too, would hang itself in a loop
> > it can't break out of due to EINTR.
> > 
> > Maybe the simplest solution would be to simply tell libfuse users to
> > call fuse_session_exit() from the SIGINT handler if they want this
> > behavior to be portable. If fuse_session_exit() is not
> > async-signal-safe, then handle SIGINT in another thread using
> > pthread_sigmask() and sigwaitinfo().
> > 
> > In any case, libfuse is relying on behavior not guarenteed by the
> > interface. The fact that a certain implementation of the interface
> > happens to provide that behavior is irrelevant.
> 
> Hello,
> 
> It's specified by POSIX:
> 
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/sem_wait.html
> 
> Sates: "The sem_wait() function is interruptible by the delivery of a signal."

This seems contradictory with EINTR being a "may fail" error, and, if
interpreted the way you want to interpret it, seems to be
contradictory with SA_RESTART semantics, since it doesn't say anything
about whether that signal is an interrupting one. I think we should
attempt to obtain a clarification on what the intent is here. Does "is
interruptible" mean that it needs to fail on signals (only without
SA_RESTART?) or simply that signal handlers must be permitted to run
(i.e. the wait can't happen with signals blocked)?

> > On a practical note, I certainly never expected sem_wait() to be capable
> > of failing due to errors other than bad programming before. Coding that
> > in would make even simple things like the consumer-producer example by
> > Dijkstra look horrible!
> 
> There's a difference between pedagogy and production code.
> 
> Just wanted to share that I was bitten myself by blindly retrying on EINTR instead
> of handling it correctly for the particular program.
> 
> For example: When using signalfd, it is critical to be handling EINTR correctly
> by getting back to the main loop so that signal handler can be executed (as it
> is not executed asynchronously). I certainly would not expect the C library to be
> eating EINTRs.

Most attempts to use EINTR (any without backoff-and-resignal) are
subject to race conditions, so it's hard to expect that you can do
thing kind of thing safely. Also, the state of stdio FILEs after EINTR
does not seem to be predictable/recoverable.

With that said, it is my intent to implement the specified
requirements as best we can, even if I disagree over whether they're
useful. So let's see if we can get answers on what's supposed to
happen.

Rich