Re: srfi-18 requirements

[Neil Jerram <neil@ossau.uklinux.net>]

"Julian Graham" <joolean@gmail.com> writes:

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

No.  I think that what SRFI-18 says about abandoned mutexes makes good
sense for threads in general, and also that it is generally good to
make Guile's behaviour here better defined.  So I'm happy for what
SRFI-18 says about abandoned mutexes to apply equally to both core and
SRFI-18 threads.

> What about a thread that calls SRFI-18's thread-join function on a
> non-SRFI-18 thread that died with an exception?

Well, according to the picture of my previous email - in which it is
the job of the thread-handler (as specified to call-with-new-thread)
to preserve the death exception - I think it is clear that a
non-SRFI-18 thread would _not_ save off its death exception in the way
that SRFI-18 says, and hence that this exception will _not_ be
available when another thread (whether SRFI-18 or not) does a
join-thread on the terminated thread.

The implication is that if you want this detail of the SRFI-18
semantics, both of the threads involved must be SRFI-18 threads.

That all seems fine to me.  I'm happy with that implication, and I
think the overall picture is clear.

>  (Are you sure you
> don't want thread exceptions in the core?  I feel like join-thread
> isn't really "complete" without them...)

Yes, I feel pretty sure about this.  SRFI-18's edicts in this area do
not feel obviously correct and generally applicable in the same way as
what it says about abandoned mutexes (for example).  Therefore, if we
can factor this out of the core - and it appears that we can - I think
we should do so.

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

Sorry if we've been giving opposing steers.  I think in a tricky patch
like this one, it's best to minimize distractions; hence I recommend
following GCS for any new or changed code, but not including
janitorial changes (even to conform to GCS) to code that would not
otherwise have changed.

(Purely janitorial changes are fine per se, but should be separate.)

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

Do you mean that timed joins is separable from the rest of the C
enhancements (e.g. timed mutex locking)?  If so, timed joins on its
own would be great.  If not (which I was expecting, although without
too much thought), it's fine for the next patch to be all of the C
code enhancements.

Regards,
        Neil