Re: signal(7): why does it say that pthread_mutex_lock() and thread_cond_wait() can fail with EINTR?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[CC += libc-help]

Hi Arkadiusz,

On Wed, Jan 01, 2025 at 11:20:26PM +0100, Arkadiusz Drabczyk wrote:
> In man/man7/signal.7 it says:
> 
> > If a blocked call to one of the following interfaces is interrupted
> > by a signal handler, then the call is automatically restarted after
> > the signal handler returns if the SA_RESTART flag was used;
> > otherwise the call fails with the error EINTR:
> > (...)
> > • pthread_mutex_lock(3), pthread_cond_wait(3), and related APIs.
> 
> I don't understand this, in my experiments neither
> pthread_mutex_lock() nor pthread_cond_wait() return EINTR even if
> signal handler was installed without using SA_RESTART flag.

Please show some minimal examples if you can.

> The
> underlying futex() call indeed fails with EINTR but it's called again
> by both glibc and musl.

I've CCed glibc, in case they can comment.  Maybe this behavior changed
at some point in the past?  I don't know.

> Additionally both
> man/man3/pthread_mutex_lock.3 and man/man3/pthread_cond_wait.3 say
> that these functions do not return EINTR.

Those pages are too old.  They were unmaintained in a Debian package,
and we adopted them recently.  I wouldn't trust them blindly.

> Is my understanding of the signal.7 wrong or does it need some work?

It might need some work.  Thanks for the report!


Have a lovely new year!
Alex

-- 
<https://www.alejandro-colomar.es/>

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Kernel Documentation]     [Netdev]     [Linux Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux