[Python-Dev] pthreads question: typedef ??? pthread_t and hacky return statements

[Tim Peters]

[Trent Mick]
> ...
> I'm all for being a hoser then.

Canadian <wink>.

> #ifdef's a-comin' down the pipe.
> One thing, the only #define that I know I have a handle on for
> Monterey is '_LP64'. Do you have an objection to that (seeing at
> is kind of misleading)? I will accompany it with an explicative
> comment of course.

Hmm!  I hate "mystery #defines", even when they do make sense.  In my last
commerical project, we had a large set of #defines in its equivalent of
pyport.h, along the lines of Py_COMPILER_MSVC, Py_COMPILER_GCC, Py_ARCH_X86,
Py_ARCH_KATMAI, etc etc.  Over time, *nobody* can remember what goofy
combinations of mystery preprocessor symbols vendors define, and vendors
come and go, and you're left with piles of code you can't make head or tail
of.  "#ifdef __SC__" -- what?

So there was A Rule that vendor-supplied #defines could *only* appear in
(that project's version of) pyport.h, used there to #define symbols whose
purpose was clear from extensive comments and naming conventions.  That
proved to be an excellent idea over years of practice!

So I'll force Python to do that someday too.  In the meantime, _LP64 is a
terrible name for this one, because its true *meaning* (the way you want to
use it) appears to be "sizeof(pthread_t) < sizeof(long)", and that's
certainly not a property of all LP64 platforms.  So how about a runtime test
for what's actually important (and it's not Monterey!)?

	if (sizeof(threadid) <= sizeof(long))
		return (long)threadid;

End of problem, right?  It's a cheap runtime test in a function whose speed
isn't critical anyway.  And it will leave the God-awful casting to the one
platform where it appears to be needed -- while also (I hope) making it
clearer that that's absolutely the wrong thing to be doing on that platform
(throwing away half the bits in the threadid value is certain to make
get_ident return the same value for two distinct threads sooner or later
...).

less-preprocessor-more-sense-ly y'rs  - tim