1.0.5.49: interrupt & GC & PA handling
authorNikodemus Siivola <nikodemus@random-state.net>
Tue, 15 May 2007 14:14:33 +0000 (14:14 +0000)
committerNikodemus Siivola <nikodemus@random-state.net>
Tue, 15 May 2007 14:14:33 +0000 (14:14 +0000)
commitb5c69cfe906a31ae57bb0f18c67af9d2eaa1dfef
tree1143d8059078e3bb7fdb0db5258edcdd149fce8c
parent2e498cbcb062ff8b6e21703838e214c6427bffe8
1.0.5.49: interrupt & GC & PA handling

 * On all FOREIGN_FUNCTION_CALL_FLAG platforms arch_pseudo_atomic_atomic is
   always accompanied by !foreign_function_call_active.

   For clarity move checking it to the a_p_a_a definitions on platforms that
   need it.

   TEST ALERT: This touches all the non-x86oid platforms, but I have
   not been able to test on them -- so a thinko/typo build-breakage is
   not impossible.

 * If we somehow ended up in interrupt_handle_pending in the middle of a PA
   section we might GC in the middle of it, or lose PA interrupted flags.

   Now we punt straight up if we get there in the middle of PA.

 * If we handled a pending interrupt outside GC-INHIBIT, but inside a PA
   section, with both GC_PENDING and SIG_STOP_FOR_GC_PENDING was true, we
   would be left running with GC_PENDING cleared without actually taking any
   action.

   The previous item actually fixes this, but for clarity make
   sig_stop_for_gc_handler clear the GC_PENDING and SIG_STOP_FOR_GC_PENDING
   iff it actually stops the thread.

 * The single UWP implementation for WITHOUT-GCING was incorrect: if
   we had a GC but no interrupts pending when checking for pending
   interrupts and GCs, and caught an asynch unwind at that point we
   could be left running with the GC pending (and/or related signals
   blocked).

   Due to the increased cost of WITHOUT-GCING, check first if GC is
   already disabled before taking the UWP code path.
src/code/sysmacs.lisp
src/runtime/alpha-arch.c
src/runtime/gc-common.c
src/runtime/hppa-arch.c
src/runtime/interrupt.c
src/runtime/mips-arch.c
src/runtime/ppc-arch.c
src/runtime/sparc-arch.c
version.lisp-expr