Why doesn't threading.join() return a value?
roy at panix.com
Sat Sep 3 01:16:29 CEST 2011
<5da6bf87-9412-46c4-ad32-f8337d56b2c3 at o15g2000vbe.googlegroups.com>,
Adam Skutt <askutt at gmail.com> wrote:
> 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.
But the whole point of higher level languages is to hide the warts of
the lower-level APIs they are built on top of. Just because a POSIX
thread can only return an int (actually, a void *) doesn't mean that
level of detail needed to be exposed at the Python threading library
> 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. If your
> thread died via an exception, it still has an error code set by the
> operating system. How would you going to distinguish those codes from
> your own?
I think you're talking about processes, not threads, but in any case,
it's a non-sequitur. Thread.join() currently returns None, so there's
no chance for confusion.
More information about the Python-list