[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAA2zVHppNtwFeRKMPJvbyJ2KfXjcGmzn2npjc12XZfM-mgcZtw@mail.gmail.com>
Date: Wed, 7 May 2025 09:39:52 -0400
From: James Y Knight <jyknight@...gle.com>
To: musl@...ts.openwall.com
Cc: "Zhao, Lihua (CN)" <Lihua.Zhao.CN@...driver.com>
Subject: Re: sigtimedwait always retry when receive -EINTR
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@...c.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
>
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
