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/01/2014 04:22 PM, Rich Felker wrote:
>> But how would you distinguish from "other spurious wakeups" that are
>> currently allowed?
> As far as I can tell that's just ***-covering by the man page with no
> basis in what the kernel actually does. If there are actually current
> situations under which it can produce EINTR without a signal, that's
> very bad. For instance sem_wait must return EINTR when actually
> interrupted by a non-SA_RESTART signal, but it's forbidden from
> returning EINTR if that didn't happen. Spurious EINTR from sem_wait in
> a program that's written not to use interrupting signals at all (and
> thus without code to handle them by restarting the call, or otherwise)
> would be serious breakage. So if the current implementation really is
> returning EINTR for reasons other than interruption-by-signal, it's a
> serious bug in sem_wait and I don't know how it can be fixed without
> fixing the bad kernel behavior.

I agree.

A user should be able to write sem_wait code and expect never to
be interrupted if only SA_RESTART signals are used.


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