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

Trent Mick trentm@ActiveState.com
Thu, 17 Aug 2000 14:22:07 -0700

On Wed, Aug 16, 2000 at 11:34:12PM -0400, Tim Peters wrote:

[Trent Mick] > I am porting Python to Monterey (64-bit AIX) and have a small > (hopefully) question about POSIX threads.

POSIX threads. "small question". HAHAHAHAHAHA. Thanks, that felt good .

Happy to provide you with cheer.

> Does the POSIX threads spec specify a C type or minimum size for > pthreadt?

or user-space arrays of structs. So I think it's safe to assume it will always fit in an integral type large enough to hold a pointer, but not guaranteed. Plain "long" certainly isn't safe in theory.

Not for pthread ports to Win64 anyway. But that is not my concern right now. I'll let the pthreads-on-Windows fans worry about that when the time comes.

> this up. On Linux (mine at least): > /usr/include/bits/pthreadtypes.h:120:typedef unsigned long int > pthreadt;

And this is a 32- or 64-bit Linux?

That was 32-bit Linux. My 64-bit Linux box is down right now, I can tell later if you really want to know.

> WHAT IS UP WITH THAT return STATEMENT? > return (long) *(long *) &threadid;

So, here's the scoop:

Thanks for trolling the cvs logs, Tim!

So one of two things can be done: 1. Bite the bullet and do it correctly. For example, maintain a static dict mapping the native pthreadself() return value to Python ints, and return the latter as Python's thread.getident() value. Much better would to implement a x-platform thread-local storage abstraction, and use that to hold a Python-int ident value. 2. Continue in the tradition already established , and #ifdef the snot out of it for Monterey. In favor of #2, the code is already so hosed that making it hosier won't be a significant relative increase in its inherent hosiness. spoken-like-a-true-hoser-ly y'rs - tim

I'm all for being a hoser then. #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.

take-off-you-hoser-ly y'rs - wannabe Bob & Doug fan

-- Trent Mick TrentM@ActiveState.com