- ;; Outside the mutex, interrupts enabled: these may cause
- ;; another GC. FIXME: it can potentially exceed maximum
- ;; interrupt nesting by triggering GCs.
- ;;
- ;; Can that be avoided by having the finalizers and hooks
- ;; run only from the outermost SUB-GC?
- ;;
- ;; KLUDGE: Don't run the hooks in GC's triggered by dying
- ;; threads, so that user-code never runs with
- ;; (thread-alive-p *current-thread*) => nil
- ;; The long-term solution will be to keep a separate thread
- ;; for finalizers and after-gc hooks.
- (when (sb!thread:thread-alive-p sb!thread:*current-thread*)
- (run-pending-finalizers)
- (call-hooks "after-GC" *after-gc-hooks* :on-error :warn)))))
+ t)))
+
+(defun post-gc ()
+ ;; Outside the mutex, interrupts may be enabled: these may cause
+ ;; another GC. FIXME: it can potentially exceed maximum interrupt
+ ;; nesting by triggering GCs.
+ ;;
+ ;; Can that be avoided by having the finalizers and hooks run only
+ ;; from the outermost SUB-GC? If the nested GCs happen in interrupt
+ ;; handlers that's not enough.
+ ;;
+ ;; KLUDGE: Don't run the hooks in GC's if:
+ ;;
+ ;; A) this thread is dying, so that user-code never runs with
+ ;; (thread-alive-p *current-thread*) => nil
+ ;;
+ ;; B) interrupts are disabled somewhere up the call chain since we
+ ;; don't want to run user code in such a case.
+ ;;
+ ;; The long-term solution will be to keep a separate thread for
+ ;; finalizers and after-gc hooks.
+ (when (sb!thread:thread-alive-p sb!thread:*current-thread*)
+ (when *allow-with-interrupts*
+ (with-interrupts
+ (run-pending-finalizers)
+ (call-hooks "after-GC" *after-gc-hooks* :on-error :warn)))))