David Kirkman dkirkman@ucsd.edu writes:
On Sat, Apr 24, 2010 at 3:43 PM, Tobias C. Rittweiler tcr@freebits.de wrote:
A thread can return multiple values. Will those be returned in list form as primary return value?
Well, in the original patch it just returned the first value, and the second value is the completed/interrupted flag. That's on obvious error, so I'm attaching a new patch that returns all of the values, plus the completed interrupted flag (for a function returning (values 1 2) thread-join will now return 1, 2, T)
That strictly couples the caller with its return sites; pain that multiple values are usually supposed to obliterate from.
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. :-)
I'm not committed to any particular semantics, other than I want thread-join to exist in some form! Naturally, I kind of like the attached patch :) (and I don't know how to get at keyword arguments in a java implemented primitive!).
You'd have to parse the &rest args by hand. I suggest you implement a %join-thread in Java which only takes required arguments, and implement JOIN-THREAD in Lisp.
Is there a proposed threading standard for common lisp, or a de facto standard?
Not really. You can look at other implementation's documentation.
-T.