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