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