Hi,
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.
Cheers,
Andy
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);
--
http://wingolog.org/
