Re: srfi-18 requirements

[Neil Jerram]

"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).

Thanks.

> 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_CRITICAL_SECTION_START;
  {
    scm_i_gc ("test");
    SCM_NEWSMOB2 (answer, tc16_jmpbuffer, 0, 0);
    SETJBJMPBUF(answer, (jmp_buf *)0);
    DEACTIVATEJB(answer);
  }
  SCM_CRITICAL_SECTION_END;
  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.

Regards,
        Neil