[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

catching scm_without_guile badness

From: Andy Wingo
Subject: catching scm_without_guile badness
Date: Thu, 31 Jul 2008 13:39:28 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)


I just spent a couple days tracking down a bug in my code that was due
to calling scm_without_guile when I wasn't actually in Guile. This
exhibited itself as a deadlock at some point in the future when a
scm_without_guile that was lower on the stack exited, it tried to take
the heap lock when the first scm_without_guile had already,
unnecessarily taken it.

The solution of course is to not call scm_without_guile when you're not
in guile. (My problem was actually that I had failed to call
scm_with_guile when re-entering into some scheme code.) The following
patch aborts if suspend() is called, but the thread was not in guile
mode. Does it make sense to yall? I guess we should benchmark it, it's a
pretty hot spot.



diff --git a/libguile/threads.c b/libguile/threads.c
index 609fc99..e0d7e74 100644
--- a/libguile/threads.c
+++ b/libguile/threads.c
@@ -383,6 +383,9 @@ suspend (void)
   scm_i_thread *t = SCM_I_CURRENT_THREAD;
+  if (t->top)
+    abort ();
   /* record top of stack for the GC */
   t->top = SCM_STACK_PTR (&t);
   /* save registers. */
@@ -459,6 +462,7 @@ guilify_self_1 (SCM_STACKITEM *base)
   scm_i_pthread_setspecific (scm_i_thread_key, t);
+  t->top = NULL;  
   scm_i_pthread_mutex_lock (&t->heap_mutex);
   scm_i_pthread_mutex_lock (&thread_admin_mutex);


reply via email to

[Prev in Thread] Current Thread [Next in Thread]