Hi Ludovic,
> The easiest way is to "cherry-pick" the change. So, assuming the commit
> is at the tip of `master', you'd do:
>
> $ git checkout branch_release-1-8
> $ git cherry-pick master
>
> ... resolve conflicts...
>
> $ git commit -a -c THE-ID-THAT-GIT-TOLD-YOU-BEFORE
>
> And that's it!
Hmm... that didn't quite seem to work. After some googling, I
discovered the following, which -- I think -- did the trick:
$ git checkout --tracking -b branch_release-1-8 origin/branch_release-1-8
...And then I just reapplied the fix by hand because it was only one
line. :) A patch against the branch is attached. Let me know if
there are any problems with it.
Regards,
Julian
From becf94cd88834d4dbb729346f34d52ca20b50d34 Mon Sep 17 00:00:00 2001
From: Julian Graham <[EMAIL PROTECTED](none)>
Date: Sat, 6 Sep 2008 20:06:17 -0400
Subject: [PATCH] Resolve a deadlock caused by not checking mutex state after calling
`SCM_TICK'.
---
libguile/ChangeLog | 5 +++++
libguile/threads.c | 2 +-
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/libguile/ChangeLog b/libguile/ChangeLog
index 5550b7a..75cd283 100644
--- a/libguile/ChangeLog
+++ b/libguile/ChangeLog
@@ -1,3 +1,8 @@
+2008-09-06 Julian Graham <[EMAIL PROTECTED]>
+
+ * threads.c (fat_mutex_lock): Resolve a deadlock caused by not
+ checking mutex state after calling `SCM_TICK'.
+
2008-08-20 Ludovic Courtès <[EMAIL PROTECTED]>
* eval.c, filesys.c, gc.c, numbers.c, posix.c, srfi-14.c,
diff --git a/libguile/threads.c b/libguile/threads.c
index 843dfca..dede85e 100644
--- a/libguile/threads.c
+++ b/libguile/threads.c
@@ -1030,9 +1030,9 @@ fat_mutex_lock (SCM mutex)
{
while (1)
{
- block_self (m->waiting, mutex, &m->lock, NULL);
if (scm_is_eq (m->owner, thread))
break;
+ block_self (m->waiting, mutex, &m->lock, NULL);
scm_i_pthread_mutex_unlock (&m->lock);
SCM_TICK;
scm_i_scm_pthread_mutex_lock (&m->lock);
--
1.5.4.3
