Date: Fri, 7 Sep 2018 00:09:33 -0400 From: "Joseph C. Sible" <josephcsible@...il.com> To: musl@...ts.openwall.com Subject: Re: Compile-time flag to enable optional EINTR's? > Can you discuss what you're trying to use EINTR for here? It's for a Python program with several threads that are often waiting on various locks, events, etc., all implemented by Python in terms of POSIX semaphores. If a thread is just waiting for work to do, and I trigger a graceful shutdown via a signal, I'd like it to give up waiting for work immediately rather than holding up shutdown until it times out doing nothing. > 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. I acknowledge the race condition. It's too bad there's no "p" variant of sem_timedwait(3) (thus of futex(2) as well) like there is of pselect vs. select. > 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. Either one of these solutions sounds okay to me. I don't have any good ideas on how to do the former, though. Joseph C. Sible
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.