[musl] sigtimedwait always retry when receive -EINTR

[musl] sigtimedwait always retry when receive -EINTR

[Zhao, Lihua (CN)]

[-- Attachment #1: Type: text/plain, Size: 810 bytes --]

Current sigtimedwait code:

int sigtimedwait(const sigset_t *restrict mask, siginfo_t *restrict si, const struct timespec *restrict timeout)
{
    int ret;
    do ret = do_sigtimedwait(mask, si, timeout);
    while (ret==-EINTR);
    return __syscall_ret(ret);
}

sigtimedwait always retry when receive -EINTR, it conflicts with https://pubs.opengroup.org/onlinepubs/9799919799/

[EINTR]
The wait was interrupted by an unblocked, caught signal. It shall be documented in system documentation whether this error causes these functions to fail.

With above implementation, sigtimedwait will dead loop to wait expected signal.

From the git log, this design is for sigwait which doesn't allow EINTR, so the EINTR check is more appropriate to do in sigwait, right?

Best Regards,
Lihua Zhao


[-- Attachment #2: Type: text/html, Size: 3509 bytes --]

Re: [musl] sigtimedwait always retry when receive -EINTR

[Markus Wichmann]

Am Wed, May 07, 2025 at 03:03:15AM +0000 schrieb Zhao, Lihua (CN):
> sigtimedwait always retry when receive -EINTR, it conflicts with https://pubs.opengroup.org/onlinepubs/9799919799/
> 
> [EINTR]
> The wait was interrupted by an unblocked, caught signal. It shall be documented in system documentation whether this error causes these functions to fail.
> 

That's a "may fail". musl only implements "may fail" for really
compelling reasons.

> With above implementation, sigtimedwait will dead loop to wait expected signal.
> 

The SYS_rt_sigtimedwait syscall will succeed if an expected (i.e.
specified in mask) signal arrives, not return -EINTR.

Ciao,
Markus

Re: [musl] sigtimedwait always retry when receive -EINTR

[Rich Felker]

On Wed, May 07, 2025 at 03:03:15AM +0000, Zhao, Lihua (CN) wrote:
> Current sigtimedwait code:
> 
> int sigtimedwait(const sigset_t *restrict mask, siginfo_t *restrict si, const struct timespec *restrict timeout)
> {
>     int ret;
>     do ret = do_sigtimedwait(mask, si, timeout);
>     while (ret==-EINTR);
>     return __syscall_ret(ret);
> }
> 
> sigtimedwait always retry when receive -EINTR, it conflicts with https://pubs.opengroup.org/onlinepubs/9799919799/

It does not conflict; that is a "may fail" (allowance for the
implementation to return with an error) not a "shall fail"
(requirement that the implementation treat the condition as an error).

Generally we avoid "may fail" conditions, and also we try to suppress
rather than pass through EINTR where possible, since various Linux
versions have had bugs where they produce EINTR under conditions where
it's not allowed, and suppressing it avoids conformance problems (and
possibly real applicaiton breakage) there.

Rich

RE: [musl] sigtimedwait always retry when receive -EINTR

[Zhao, Lihua (CN)]

Thank you for your reply. The original intention of sigtimewait is to selectively wait for specific signals, so EINTR may mislead the application. I accept this suggestion.

Lihua

-----Original Message-----
From: Rich Felker <dalias@libc.org> 
Sent: Wednesday, May 7, 2025 8:56 PM
To: Zhao, Lihua (CN) <Lihua.Zhao.CN@windriver.com>
Cc: musl@lists.openwall.com
Subject: Re: [musl] sigtimedwait always retry when receive -EINTR

CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know the content is safe.

On Wed, May 07, 2025 at 03:03:15AM +0000, Zhao, Lihua (CN) wrote:
> Current sigtimedwait code:
>
> int sigtimedwait(const sigset_t *restrict mask, siginfo_t *restrict 
> si, const struct timespec *restrict timeout) {
>     int ret;
>     do ret = do_sigtimedwait(mask, si, timeout);
>     while (ret==-EINTR);
>     return __syscall_ret(ret);
> }
>
> sigtimedwait always retry when receive -EINTR, it conflicts with 
> https://pubs.opengroup.org/onlinepubs/9799919799/

It does not conflict; that is a "may fail" (allowance for the implementation to return with an error) not a "shall fail"
(requirement that the implementation treat the condition as an error).

Generally we avoid "may fail" conditions, and also we try to suppress rather than pass through EINTR where possible, since various Linux versions have had bugs where they produce EINTR under conditions where it's not allowed, and suppressing it avoids conformance problems (and possibly real applicaiton breakage) there.

Rich

Re: [musl] sigtimedwait always retry when receive -EINTR

[James Y Knight]

[-- Attachment #1: Type: text/plain, Size: 1383 bytes --]

It seems a bit surprising (at least to me) that this particular API is
specified by POSIX as "may fail" instead of "shall fail" with EINTR. I
think every other similar "wait for X or timeout" API in POSIX specifies
"shall fail" with EINTR.

On Wed, May 7, 2025 at 8:55 AM Rich Felker <dalias@libc.org> wrote:

> On Wed, May 07, 2025 at 03:03:15AM +0000, Zhao, Lihua (CN) wrote:
> > Current sigtimedwait code:
> >
> > int sigtimedwait(const sigset_t *restrict mask, siginfo_t *restrict si,
> const struct timespec *restrict timeout)
> > {
> >     int ret;
> >     do ret = do_sigtimedwait(mask, si, timeout);
> >     while (ret==-EINTR);
> >     return __syscall_ret(ret);
> > }
> >
> > sigtimedwait always retry when receive -EINTR, it conflicts with
> https://pubs.opengroup.org/onlinepubs/9799919799/
>
> It does not conflict; that is a "may fail" (allowance for the
> implementation to return with an error) not a "shall fail"
> (requirement that the implementation treat the condition as an error).
>
> Generally we avoid "may fail" conditions, and also we try to suppress
> rather than pass through EINTR where possible, since various Linux
> versions have had bugs where they produce EINTR under conditions where
> it's not allowed, and suppressing it avoids conformance problems (and
> possibly real applicaiton breakage) there.
>
> Rich
>

[-- Attachment #2: Type: text/html, Size: 1933 bytes --]

Re: [musl] sigtimedwait always retry when receive -EINTR

[Rich Felker]

On Wed, May 07, 2025 at 09:39:52AM -0400, James Y Knight wrote:
> It seems a bit surprising (at least to me) that this particular API is
> specified by POSIX as "may fail" instead of "shall fail" with EINTR. I
> think every other similar "wait for X or timeout" API in POSIX specifies
> "shall fail" with EINTR.

Yes, but:

See select which has the text "If SA_RESTART has been set for the
interrupting signal, it is implementation-defined whether the function
restarts or returns with [EINTR]." and poll which has the text "A
signal was caught during poll() or ppoll()."

Normally the wording "interrupted ... by a signal" only applies when a
signal handler installed without SA_RESTART was executed. So without
an exception allowing non-interrupting signal handlers to generate
EINTR, we have to worry about whether Linux might generate EINTR for
non-interrupting ones, which would be nonconforming, and patch around
that.

When allowed, it's safer and easier not to do that and just suppress
it.


> On Wed, May 7, 2025 at 8:55 AM Rich Felker <dalias@libc.org> wrote:
> 
> > On Wed, May 07, 2025 at 03:03:15AM +0000, Zhao, Lihua (CN) wrote:
> > > Current sigtimedwait code:
> > >
> > > int sigtimedwait(const sigset_t *restrict mask, siginfo_t *restrict si,
> > const struct timespec *restrict timeout)
> > > {
> > >     int ret;
> > >     do ret = do_sigtimedwait(mask, si, timeout);
> > >     while (ret==-EINTR);
> > >     return __syscall_ret(ret);
> > > }
> > >
> > > sigtimedwait always retry when receive -EINTR, it conflicts with
> > https://pubs.opengroup.org/onlinepubs/9799919799/
> >
> > It does not conflict; that is a "may fail" (allowance for the
> > implementation to return with an error) not a "shall fail"
> > (requirement that the implementation treat the condition as an error).
> >
> > Generally we avoid "may fail" conditions, and also we try to suppress
> > rather than pass through EINTR where possible, since various Linux
> > versions have had bugs where they produce EINTR under conditions where
> > it's not allowed, and suppressing it avoids conformance problems (and
> > possibly real applicaiton breakage) there.
> >
> > Rich
> >