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 Tue, Dec 02, 2014 at 09:45:18PM +0100, Torvald Riegel wrote:
> > 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.
> EINTR is a 'may fail'.  POSIX states that sem_wait is interruptible, but
> I read this as allowing interruption, not requiring it.

Indeed, I had missed this. It seems preferable that an implementation
not act on such interruptions, and at least this choice allows an
"out" if the kernel has the broken behavior of spurious EINTRs, but I
still think it's better for the kernel never to return EINTR except
for genuine interruption-by-signal.

> The signal man pages list sem_wait as having to return EINTR if
> interrupted, but what's the point?

This applies to all uses of interrupting signal handlers, which is why
I personally think they should be deprecated. However, you can work
around the issue by repeating the signal with exponential backoff
until the thread sending the signal can determine that the target
thread has acted upon the interruption.


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