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.