1.0.26.7: use a signal for SIG_STOP_FOR_GC > SIGSEGV on Linux
commit619189958917e80786d5bb2efa4dc38d908d2553
authorGabor Melis <mega@hotpop.com>
Tue, 17 Mar 2009 11:27:08 +0000 (17 11:27 +0000)
committerGabor Melis <mega@hotpop.com>
Tue, 17 Mar 2009 11:27:08 +0000 (17 11:27 +0000)
tree18fa5934e28d6d30b4a52937611a1a5a7678d5a2
parentb6a842dc8eb0c3aa0364c26b5b41bfc3b38fef31
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#
src/runtime/bsd-os.h
src/runtime/darwin-os.h
src/runtime/linux-os.h
src/runtime/sunos-os.h
version.lisp-expr