From: Gabor Melis <mega@hotpop.com>
Date: Tue, 17 Mar 2009 11:27:08 +0000 (+0000)
Subject: 1.0.26.7: use a signal for SIG_STOP_FOR_GC > SIGSEGV on Linux
X-Git-Url: http://repo.macrolet.net/gitweb/?a=commitdiff_plain;h=619189958917e80786d5bb2efa4dc38d908d2553;hp=619189958917e80786d5bb2efa4dc38d908d2553;p=sbcl.git

1.0.26.7: use a signal for SIG_STOP_FOR_GC > SIGSEGV on Linux

On Linux a signal generated by pthread_kill() with a signum that's
lower than SIGSEGV can be delivered before a synchronously triggered
SIGSEGV. This means that the sigsegv handler will be invoked with its
context pointing to the handler for the signal that pthread_kill()
sent. It's not really specific to SIGSEGV, it's the same for any
synchronously generated signal.

To work around this, we must never pthread_kill() with a signal with a
lower signum than any of the synchronously triggered signals that we
use: SIGTRAP, SIGSEGV, etc. In practice, currently we only send
SIGPIPE to indicate that the thread interruption queue may need to be
looked at and SIG_STOP_FOR_GC that's defined as SIGUSR1 currently.

With SIGUSR1 being 10 and SIGSEGV 11 this can make
handle_guard_page_triggered lose badly if GC wants to stop the thread
at the same time. So let's use SIGUSR2 instead that's 12. Do the same
on other OSes they may have same bug.

See thread "Signal delivery order" from 2009-03-14 on
kernel-devel@vger.kernel.org:

http://groups.google.com/group/fa.linux.kernel/browse_thread/thread/6773ac3dcb867da3#
---