Re: srfi-18 requirements

[Julian Graham]

> > 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:


Excellent -- I'll let you know if I can think of a deterministic way
to reproduce that from user code.


At any rate, let me pop a few frames off the stack.  The two remaining
changes for the core features patch were providing a join_thread that
could indicate a timeout without throwing an SRFI-18 exception; and
providing a well-defined fat_mutex_lock that doesn't rely on the
SRFI-18 notion of mutex state.  Two questions:

* What would be an appropriate way for join_thread to indicate a
timeout?  Given that it's a primitive that can be called from Guile, I
take it that the standard C approach of passing a pointer to a flag is
out of the question.  Would it be good enough to have it return #f on
timeout (even if that leaves some amiguity about whether there was a
timeout or just a lack of a thread return value)?  Is there a core
exception it could throw?

* What should be the behavior of fat_mutex_lock when attempting to
lock an abandoned mutex -- in your earlier email, you seemed amenable
to the parts of SRFI-18 that shore up some of the poorly-defined
threading behavior in core threads.  So should locking an abandoned
mutex be an error?  If so, what kind?  Or should locking an abandoned
mutex not be an error at all unless you do it using the SRFI-18 API?


Regards,
Julian