Re: srfi-18 requirements

[Julian Graham]

Hi Neil,

(Apologies for the delay in getting this to you -- a host of
professional and personal crises reared up over the last week or so.)

Find attached a patch (in two parts -- sorry, still getting used to
git) to the core threading code that includes the changes we
discussed, specifically:

* Re-added support for locking mutexes with an owner other than the
current thread
* Enabled the previously ifdef'd out functions scm_mutex_owner and
scm_mutex_level
* Added a new function, scm_mutex_locked_p, useful for distinguishing
between unlocked and unowned mutex states.
* Updated the threads.test file to reflect the changes above
* Updated the documentation in api-scheduling.texi to reflect the changes above
* Updated the ChangeLog to reflect the changes above

Also attached are updated versions of the Scheme SRFI-18
implementation as well as the SRFI-18-specific test code.

A couple of notes: For purposes of elegance, I've changed semantics of
fat_mutex.level -- where previously all non-recursive mutexes had a
level of -1, recursiveness is now denoted by an integer field on
fat_mutex.  Any mutex (recursive or not) is in a locked state iff its
level is greater than 0.

Second, during the testing I did for this round of changes, I noticed
a few more deadlocks that I believe are related to the existing core
threading model (as opposed to the changes included in this patch).
These seem to crop up when I run overnight tests on modified core
code, probably because different timings and thread interactions are
introduced.  I think I've got fixes for some of them, and I'll
follow-up in a separate mailing list thread.


Regards,
Julian

0001-latest-set-of-SRFI-18-support-changes-to-core-thread.patch
Description: Text Data

0002-ChangeLog-updates-for-latest-set-of-SRFI-18-changes.patch
Description: Text Data

srfi-18.scm
Description: Binary data

srfi-18.test
Description: Binary data