In article <5da6bf87-9412-46c4-ad32-f8337d56b...@o15g2000vbe.googlegroups.com>, Adam Skutt <ask...@gmail.com> wrote:
> On Sep 2, 10:53 am, Roy Smith <r...@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 level. > 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.
-- http://mail.python.org/mailman/listinfo/python-list
