Why doesn't threading.join() return a value?

[Alain Ketterlin]

Adam Skutt <askutt at gmail.com> writes:

> On Sep 2, 10:53 am, Roy Smith <r... at panix.com> wrote:
>> I have a function I want to run in a thread and return a value.  It
>> seems like the most obvious way to do this is to have my target
>> function return the value, the Thread object stash that someplace, and
>> return it as the return value for join().
>> > Yes, I know there's other ways for a thread to return values (pass the
>> target a queue, for example), but making the return value of the
>> target function available would have been the most convenient.  I'm
>> curious why threading wasn't implemented this way.
>
> I assume it is because the underlying operating system APIs do not
> support it.  Windows and POSIX threads only support returning an
> integer when a thread exits, similar to the exit code of a process.

Sorry, you're wrong, at least for POSIX threads:

void pthread_exit(void *value_ptr);
int pthread_join(pthread_t thread, void **value_ptr);

pthread_exit can pass anything, and that value will be retrieved with
pthread_join. Threads of a process share their address space, there is
no reason to restrict their return value to an int.

> More importantly, there's no way to tell whether the exit code of a
> thread was set by user code or by the system.  Even worse, some of
> those integer values are reserved by some operating systems.

I'm not sure what you are talking about here. Maybe you confuse threads
with processes?

Re. the original question: since you can define your own Thread
subclass, with wathever attribute you want, I guess there was no need to
use join() to communicate the result. The Thread's run() can store its
result in an attribute, and the "client" can get it from the same
attribute after a successful call to join().

-- Alain.