Re: sem_wait and EINTR

[Markus Wichmann <nullplan@gmx.net>]

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.

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!

Ciao,
Markus