From: Nikodemus Siivola <nikodemus@random-state.net>
Date: Tue, 15 May 2007 14:14:33 +0000 (+0000)
Subject: 1.0.5.49: interrupt & GC & PA handling
X-Git-Url: http://repo.macrolet.net/gitweb/?a=commitdiff_plain;ds=sidebyside;h=b5c69cfe906a31ae57bb0f18c67af9d2eaa1dfef;hp=b5c69cfe906a31ae57bb0f18c67af9d2eaa1dfef;p=sbcl.git

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.
---