[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250507150023.GF1827@brightrain.aerifal.cx>
Date: Wed, 7 May 2025 11:00:23 -0400
From: Rich Felker <dalias@...c.org>
To: James Y Knight <jyknight@...gle.com>
Cc: musl@...ts.openwall.com,
"Zhao, Lihua (CN)" <Lihua.Zhao.CN@...driver.com>
Subject: Re: sigtimedwait always retry when receive -EINTR
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@...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
> >
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.
