As reported by Rich Felker: I see no code in the kernel whereby a "spurious wakeup", or anything other than interruption by a signal handler that's not SA_RESTART, can cause futex to fail with EINTR. In general, overloading of EINTR and/or spurious EINTRs from a syscall make it impossible to use that syscall for implementing any function where EINTR is a mandatory failure on interruption-by-signal, since there is no way for userspace to distinguish whether the EINTR occurred as a result of an interrupting signal or some other reason. The kernel folks have gone to great lengths to fix spurious EINTRs (see signal(7) for history), especially by non-interrupting signal handlers, including in futex, and allowing EINTR here would be contrary to that goal. It's my belief that the "or a spurious wakeup" text should simply be removed. The reason I'm raising this topic is its relevance to a thread on libc-alpha: [RFC] mutex destruction (#13690): problem description and workarounds The bug and mailing list discussions to which Rich refers are: https://sourceware.org/bugzilla/show_bug.cgi?id=13690 https://sourceware.org/ml/libc-alpha/2014-12/threads.html#0001 Torvald Riegel also reported the same issue, and Thomas Gleixner noted that the "EINTR on spurious wakeup" behavior went away in Linux 2.6.22. See the LKML thread, "futex() man page update help request", Jan 2015: http://thread.gmane.org/gmane.linux.kernel/1703405/focus=7734 Reported-by: Rich Felker <dalias@libc.org> Reported-by: Torvald Riegel <triegel@redhat.com> Reported-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Michael Kerrisk <mtknpages@gmail.com>