Re: srfi-18 requirements

[Julian Graham]

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


Works for me.  I'll try to have something to you this weekend.


Regards,
Julian