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

Mark Favas m.favas@per.dem.csiro.au
Sat, 19 Aug 2000 03:08:36 +0800

OK -

return (long) threadid;

compiles without warnings, and all tests pass on OSF/1 (aka Tru64 Unix). Removing the "volatile" is also fine for me, but may affect Vladimir. I'm still a bit (ha!) confused by Tim's comments that the function is bogus for OSF/1 because it throws away half the bits, and will therefore result in id collisions - this will only happen on platforms where sizeof(long) is less than sizeof(pointer), which is not OSF/1 (but is Win64). Also, one of the suggested tests only cast the pointer to a long SIZEOF_PTHREAD_T < SIZEOF_LONG - that should surely be <= ...

In summary, whatever issue there was for OSF/1 six (or so) years ago appears to be no longer relevant - but there will be the truncation issue for Win64-like platforms.

Mark

Fredrik Lundh wrote:

trent mick wrote: > return (long) *(long *) &threadid; from what I can tell, pthreadt is a pointer under OSF/1. I've been using OSF/1 since the early days, and as far as I can remember, you've never needed to use stupid hacks like that to convert a pointer to a long integer. an ordinary (long) cast should be sufficient. > Could this be changed to > return threadid; > safely? safely, yes. but since it isn't a long on all platforms, you might get warnings from the compiler (see Mark's mail). ::: from what I can tell, it's compatible with a long on all sane plat- forms (Win64 doesn't support pthreads anyway ;-), so I guess the right thing here is to remove volatile and simply use: return (long) threadid; (Mark: can you try this out on your box? setting up a Python 2.0 environment on our alphas would take more time than I can spare right now...)

-- Email - m.favas@per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913