Re: srfi-18 requirements

[Neil Jerram]

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

As previously discussed, I think it's better for the core behavior to
be defined - i.e. by signaling some kind of error - than undefined as
it is now.

I suggest we introduce 'locking-abandoned-mutex-error as a new throw
key, and fat_mutex_lock() can throw that.  That's then trivial for the
SRFI-18 API to catch and reraise as a SRFI-34/35 exception.

OK?

Regards,
        Neil