Re: Q: SEGSEGV && uc_mcontext->ip (Was: Signal delivery order)

[Roland McGrath <roland@redhat.com>]

> First of all, perhaps I missed somethings and this is solvable without
> kernel changes, but I can't see how.

It depends what kind of "solved" you mean.

Signals pending for the thread are always delivered before signals pending
for the process.  POSIX does not guarantee this to the application, but it
has always been so in Linux and it's fine enough to rely on that.  Truly
externally-generated and asynchronous signals go to the process, so it's
really only pthread_kill use within your own program that raises the issue.

Among signals pending for the thread, signals < SIGRTMIN are always
delivered before ones >= SIGRTMIN.  POSIX does not guarantee this to the
application, but it has always been so in Linux and it's fine enough to
rely on that.  The most sensible thing to use with pthread_kill is some
SIGRTMIN+n signal anyway, since they are never confused with any other use.
If your program is doing that, you don't have a problem.

So on the one hand it seems pretty reasonable to say it's "solved" by
accepting it when we say, "Welcome to Unix, these things should have
stopped surprising you in the 1980s."  It's a strange pitfall of how
everything fits together, granted.  But you do sort of have to make an
effort to do things screwily before you can fall into it.

All that said, it's actually probably a pretty easy hack to arrange that
the signal posted by force_sig_info is the first one dequeued in all but
the most utterly strange situations.


Thanks,
Roland