Thanks for comments.
On 2006/12/09 05:07, Gábor Melis wrote:
> On Friday 08 December 2006 16:49, Nikodemus Siivola wrote:
>> I was wondering if there is any potential badness since the the
>> native thread may still be alive when the results are returned, but
>> cannot think of anything.
> Me neither. In general native threads are supposed to be invisible to
> user level lisp code, that is the lisp level thread abstraction must
> not leak this way.
I considered the potential problems carefully, but did not noticed
anything. If something is wrong, I'm happy to fix it.
>> Maybe all the values of the function, and call it THREAD-VALUES?
>> (Since the semantics are a bit different from "classic" join:
>> multiple threads can wait for the values using this, but pthread_join
>> only works for one waiter.
> Well, I wouldn't worry about pthread naming and much prefer consistent
> lisp level naming. JOIN-THREAD is a very natural name (albeit the name
> might come from pthreads, I don't know) while THREAD-VALUES gives the
> impression that multiple values are supported which is not the case
> (oh, and that should be documented too). Also, THREAD-VALUES follows
> an accessor naming convention and it could be a bit surprising for it
> to block.
The name "JOIN" is mainly taken from pthread, but I investigated other
thread libraries. I think it's a limitation of pthread library that
only one call is allowed on pthread_join(). Languages which have GC,
e.g. Python or Java, do not have such limitation and multiple calls to
join() are allowed.
> One thing that needs some consideration is what result (if any) should
> be available if the thread didn't return normally. In the patch the
> result is NIL but maybe one needs to distuinguish NIL and
> did-not-return-normally. A second return value as in gethash sounds
> good to me, but that can be added later.
I updated the patch.
1. Include docstring of join-thread in threading.texinfo.
Current documentation seems not to mention the result of the function
passed to make-thread. So I just included the docstring.
2. Support for multiple values result.
The values are stored as a list. I think the overhead is ignorable
compared to the total cost of thread creation.
3. Add optional 2nd argument to join-thread.
If the thread does not exit normally, the 2nd argument is used as the
value. I'm not sure this interface is best. Other possibilities are:
throws a condition, returns terminate state as values, etc.
4. Testcase for 2 and 3