[armedbear-devel] threads, join, clos

Tobias C. Rittweiler tcr at freebits.de
Sat Apr 24 22:43:07 UTC 2010

David Kirkman <dkirkman at ucsd.edu> writes:

> On Sat, Apr 24, 2010 at 1:57 AM, Erik Huelsmann <ehuels at gmail.com> wrote:
>> I have one question regarding the patch though: How would the caller
>> know the difference between the scenario where an Interrupted
>> exception occurs and the one where the thread is really joined?
>> Should we use the return value NIL to signal "not joined" and T for "joined"?
> Yes!  Here is an updated patch that does that.
> The other option for thread-join return values is to have
> it return the value of the function used in make-thread.
> That way thread-join will both wait for the thread to finish
> and collect it's value, and I don't have to set up global
> variables to collect the results.  (Which is the way I always
> *want* join to work!)
> I've included a second patch in which implements join that way.  It
> also returns a second T/NIL value indicating if the thread finished
> normally or was interrupted.  The only disadvantage to this is that
> in other languages join either returns nothing or a
> success/failure code.

A thread can return multiple values. Will those be returned in list form
as primary return value?

SBCL returns the values as multiple values, and signals an error in case
it couldn't join. I'm not sure what interface I'd like more. On SBCL,
you pretty much always have to wrap HANDLER-CASE around join-thread
which makes it unappropriate to use with MAPC.

At the project I'm currently working on, I added the following wrapper:

  (defun join-thread (thread &key timeout
                                  (on-timeout :timeout)
                                  (on-failure :error))

The ON-TIMEOUT/FAILURE arguments are returned as primary results, making
it potentially ambiguous (does :error come from the return value of the
thread or because of a failure?); however the user can specify these
values -- and the user should almost always know in what range a
thread's return value is going to be -- so it's my humble opinion on how
I think JOIN-THREAD should look like. :-)


More information about the armedbear-devel mailing list