From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: Compile-time flag to enable optional EINTR's?
Date: Thu, 6 Sep 2018 22:16:57 -0400 [thread overview]
Message-ID: <20180907021657.GJ1878@brightrain.aerifal.cx> (raw)
In-Reply-To: <CABpewhEpRqwDgfA4PdtYr8Rmx7z+JWJ9nqf=Bin+fE3HsWsPRg@mail.gmail.com>
On Thu, Sep 06, 2018 at 09:26:19PM -0400, Joseph C. Sible wrote:
> I know musl has reasons not to enable EINTR where it's optional (such
> as c0ed5a20), but there are a lot of use cases where the lack of it
> causes problems. As a compromise, would a patch to add a ./configure
> flag (say --enable-optional-eintr) to change this behavior be
> accepted?
Not having configurable switches is a very conscious decision for
musl. The exponential complexity that results makes it nearly
impossible to manage testing, and was a big part of what happened to
uclibc. Instead we aim to support as wide a range of needs/use cases
as possible with a single configuration.
Can you discuss what you're trying to use EINTR for here? Most uses of
EINTR have fundamental race conditions -- if the signal arrives just
moments before the syscall you hoped to interrupt, it won't get
interrupted, and will block until some other event lets it proceed.
If we did want to bring back EINTR for sem_[timed]wait, I think the
right thing to do would be to look for a workaround for the underlying
kernel bug, or some way to detect it and avoid honoring the EINTRs
that happen on old buggy kernels. One thing that was once suggested,
but I didn't really like it, was ignoring (retrying on) EINTR for
sem_wait, where the caller may not be prepared for it to return
without having decremented the semaphore value, but honoring it
(failing) for sem_timedwait, where the caller has to be prepared for
the possibility of failure (ETIMEDOUT) anyway. I didn't do much
research into whether this would be conforming but I think it would.
Rich
next prev parent reply other threads:[~2018-09-07 2:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-07 1:26 Joseph C. Sible
2018-09-07 2:16 ` Rich Felker [this message]
2018-09-07 4:09 ` Joseph C. Sible
2018-09-07 13:15 ` Rich Felker
2018-09-07 13:57 ` Joseph C. Sible
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180907021657.GJ1878@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).