This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] mutex destruction (#13690): problem description and workarounds

On 12/04/2014 09:32 AM, Torvald Riegel wrote:
>> I agree. The conflation of EINTR for non-signal use is IMO going to be
>> a design decision we regret in the future.
> I'd rather see the fault in POSIX semantics, and it not making it clear
> that signal handlers should do sem_post if they need to reliably
> interrupt a sem_wait.

If we are going to disallow a signal to interrupt sem_post we should just
change the semantics, version the interface, and document that glibc no
longer ever returns EINTR for sem_wait, and that the right way to interrupt
it is with a signal handler that does sem_post.

This prevents users from complaining that what they observe with strace
and gdb is a signal arriving after the sem_wait, but not interrupting it.
We can claim the user is looking under the hood, but that's what they do,
and if we can possibly avoid those arguments we win. We know we're right,
we know we don't want to allow timing to imply ordering, but we need time
to educate developers (and that looking under the hood leads to non-obvious

I really wish the kernel returned some other error code for woken up
vs. signal. Is it not possible to get the kernel to distinguish these
two? Am I forgetting something?

> Allowing spurious wake-ups in futex_wait anywhere is not a bad thing --
> remember that this works just fine in condvars, and nobody is
> complaining about that.  The issue is trying to merge in things like
> signals without a proper synchronization scheme backing that up.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]