[Python-Dev] pthreads question: typedef ??? pthread_t and hacky return statements (original) (raw)

Tim Peters tim_one@email.msn.com
Thu, 17 Aug 2000 23:39:29 -0400

[Trent Mick]

... I'm all for being a hoser then.

Canadian .

#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