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

Adam Skutt askutt at gmail.com
Sat Sep 3 00:02:08 CEST 2011

On Sep 2, 4:14 pm, Chris Torek <nos... at torek.net> wrote:
> In article <bf50c8e1-1476-41e1-b2bc-61e329bfa... at s12g2000yqm.googlegroups.com>
> Adam Skutt  <ask... at gmail.com> wrote:
> >No, it can only pass a void*, which isn't much better than passing an
> >int.
> It is far better than passing an int, although it leaves you with
> an annoying storage-management issue, and sidesteps any reasonable
> attempts at type-checking (both of which are of course "par for
> the course" in C).

And when written out, makes it sound distinctly worse than passing an
int :p.  And let's not kid ourselves, unless you're a C programmer, it
is distinctly worse than passing an int.  Heck, your example (snipped)
goes out of your way to unnecessarily leverage the functionality
provided by pthreads.

> Some manual pages are clearer about this than others.  Here is one
> that I think is not bad:
>     The symbolic constant PTHREAD_CANCELED expands to a constant
>     expression of type (void *), whose value matches no pointer to
>     an object in memory nor the value NULL.
> So, provided you use pthread_exit() "correctly" (always pass either
> NULL or the address of some actual object in memory), the special
> reserved value is different from all of "your" values.

Unfortunately, I'm not sure all implementations behave that way.  Not
that cancellation is really worth bothering with anyway, but it's a
pretty nasty corner case.


More information about the Python-list mailing list