[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 6 Sep 2018 22:16:57 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Compile-time flag to enable optional EINTR's?
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
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.
