[Top][All Lists]

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

Re: srfi-18 requirements

From: Neil Jerram
Subject: Re: srfi-18 requirements
Date: Sun, 03 Feb 2008 00:30:06 +0000
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)

"Julian Graham" <address@hidden> writes:

> On Jan 24, 2008 8:38 PM, Julian Graham <address@hidden> wrote:
>> > - we apply the generic / bug fix patch that you already posted, except
>> >   without the extra thread_admin_mutex locking (which I think we
>> >   concluded we can't justify) - that will be to HEAD
>> Agreed, though see below...
> Actually, in light of Neil's apt suggestion that we get this thing
> back on track, I resolve to stop fussing about deadlocks for the time
> being -- find attached the patch described above (1 deadlock -- the
> jmpbuf critical section one -- and the thread-specific mutex).


> Let me know if I've missed anything.

I don't think so, and I plan to apply this very soon.  I've found a
reliable recipe for reproducing the critical section problem: if a
scm_i_gc call is added to make_jmpbuf (), like this:

static SCM
make_jmpbuf (void)
  SCM answer;
    scm_i_gc ("test");
    SCM_NEWSMOB2 (answer, tc16_jmpbuffer, 0, 0);
    SETJBJMPBUF(answer, (jmp_buf *)0);
  return answer;

Then "make check" hangs every time, in the way you described, when
running the system* part of test-suite/standalone/test-system-cmds.

(It happens because scm_system_star calls scm_sigaction, which calls
ensure_signal_delivery_thread, which spawns a new thread; and then
immediately after that, scm_sigaction enters a critical section.)

So now I just want to find a way of making this happen regressibly,
without actually adding the scm_i_gc call to the checked in code.


reply via email to

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