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

[Alain Ketterlin]

Adam Skutt <askutt at gmail.com> writes:

> On Sep 2, 2:23 pm, Alain Ketterlin <al... at dpt-info.u-strasbg.fr>
> wrote:
>> 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.
>
> No, it can only pass a void*, which isn't much better than passing an
> int.

We'll have to disagree. A void* simply can point to anything you want.
Since thread stacks disappear at end of thread, only dynamically
allocated memory can be used to store the result. That's why you get a
pointer. There is no restriction on that pointer provided it doesn't
point to memory that has been deallocated.

> Passing a void* is not equivalent to passing anything, not even in C.
> Moreover, specific values are still reserved, like PTHREAD_CANCELLED.

Thread cancellation is program logic (pthread_cancel), it doesn't mean
you thread crashed, it means your program decided to cancel the thread.
If you still care about the return value after having called
pthread_cancel(), 

> Yes, it was strictly inappropriate for me to say both return solely
> integers, but my error doesn't meaningful alter my description of the
> situation. The interface provided by the underlying APIs is not
> especially usable for arbitrary data transfer.

Again, I may misunderstand your wording, but there is no "data transfer"
at all, since memory is shared between threads.

> Doubly so when we're discussing something like Python's threading
> module.

The OP was clearly discussing the case where a thread has a result, and
how to get it back. POSIX threads let you do that. There are of course
tons of other ways to do the same thing. Win32 will force you to use
some other way.

>> I'm not sure what you are talking about here. Maybe you confuse threads
>> with processes?
>
> Windows threads have exit codes, just like processes.  At least one
> code is reserved and cannot be used by the programmer.

Is that STILL_ACTIVE that we are talking about? That's an artefact of
the design of GetExitCodeThread, which will return either the thread
exit code or its own error code. The python lib could easily hide this,
and use run()'s return value to store the (python) result somewhere.

-- Alain.