Re: srfi-18 requirements

[Julian Graham]

Hi Neil,

> > Of course.
>
> Good, thanks.

Find attached a patch against HEAD that includes only the bug fix
stuff (2 deadlocks and use of thread-specific admin mutex) from the
original patch, modified to change make_jmpbuf instead of the signal
delivery code.

With regard to your comments about the rest of the patch, agreed, except:

Given the similarities between the existing Guile threading code and
SRFI-18, what level of comptability between these two domains will be
supported?  For example, SRFI-18 specifies that threads waiting on a
mutex held by a thread that exits should be notified of the exit and
that one of them will then be able to lock that mutex.  Given the
changes you describe below, will this behavior only work if all the
components in the user's code were created using the SRFI-18 API?

What about a thread that calls SRFI-18's thread-join function on a
non-SRFI-18 thread that died with an exception?  (Are you sure you
don't want thread exceptions in the core?  I feel like join-thread
isn't really "complete" without them...)


> Finally, there are quite a few spurious changes (or perhaps just that
> I don't understand yet) in patch: whitespace, line break and docstring
> changes.  Can you revert all these, as they only confuse the overall
> picture?

This may have just been stuff that Ludovic asked me to clean up (or
that I just cleaned up ad-hoc).  It can all go.


> I'm sorry that I'm asking for some significant changes here, but I
> hope that you'll agree that they make the enhancement clearer, and in
> particular that it is a good thing to reduce the changes that we need
> to make to the C code.  Please let me know what you think.

Not a problem.  Thank you for taking the time to all this analysis.
What's the next thing you'd like me to submit?  How about (2), the
enhancement patch for timed joins?


Regards,
Julian

srfi-18-bugs.HEAD.patch
Description: Text Data