-#ifdef LISP_FEATURE_WIN32
- /* Actually this part looks almost good to go for
- * Windows too, but currently we never save anything
- * on Windows, so ending up here would be pretty bad. */
- lose("Pending interrupts unimplemented on Windows.");
-#else
- struct thread *thread = arch_os_get_current_thread();
- struct interrupt_data *data = thread->interrupt_data;
+ /* There are three ways we can get here. First, if an interrupt
+ * occurs within pseudo-atomic, it will be deferred, and we'll
+ * trap to here at the end of the pseudo-atomic block. Second, if
+ * the GC (in alloc()) decides that a GC is required, it will set
+ * *GC-PENDING* and pseudo-atomic-interrupted, and alloc() is
+ * always called from within pseudo-atomic, and thus we end up
+ * here again. Third, when calling GC-ON or at the end of a
+ * WITHOUT-GCING, MAYBE-HANDLE-PENDING-GC will trap to here if
+ * there is a pending GC. */
+
+ /* Win32 only needs to handle the GC cases (for now?) */
+
+ struct thread *thread;
+
+ /* Punt if in PA section, marking it as interrupted. This can
+ * happenat least if we pick up a GC request while in a
+ * WITHOUT-GCING with an outer PA -- it is not immediately clear
+ * to me that this should/could ever happen, but better safe then
+ * sorry. --NS 2007-05-15 */
+ if (arch_pseudo_atomic_atomic(context)) {
+ arch_set_pseudo_atomic_interrupted(context);
+ return;
+ }
+
+ thread = arch_os_get_current_thread();