[Python-Dev] Should Python #define _POSIX_THREADS?

[Tim Peters]

[Jason Tishler, passing on someone's objection to Python #define'ing
 _POSIX_THREADS sometimes]

Right or wrong, it's too late to change this for 2.1 (IMO).  Thread support
across platforms is very touchy, because so poorly standardized and
implemented across vendors, and fiddling with *any* of that support code is
very dangerous.  Can you swear that Python never #define'ing _POSIX_THREADS
on its own won't break threading on some other platform?  If not, changing it
needs *lots* of lead time for x-platform testing.

> ...
> The author of the recent Cygwin pthreads enhancements states that
> _POSIX_THREADS is a kernel level #define and should not be defined in
> user level code.  Please see the following for his reasoning:
>
>     http://sources.redhat.com/ml/cygwin/2001-03/msg01693.html
>
> Unfortunately, I am not knowledgeable is this area.  Can someone please
> confirm or refute the above claim?

At heart, the claim was based on little more than "I said so", as far as I
could see.  What does the POSIX pthreads standard say?  I haven't had an
employer willing to buy me a copy of that (expensive) document since 1992, so
I can't say (and POSIX stds are not available for online browsing).

He's certainly right that _POSIX_THREADS "is _NOT_ a userland symbol".  *All*
identifiers beginning with an underscore and followed by another underscore
or an uppercase letter are reserved names in std C, for use by the
implementation (incl. system libraries).  But lots of stuff violates that
rule, so I'm afraid it's not a killer argument in practice (although it's a
*good* argument!).

BTW, it's safe to remove this from thread.c:

#ifdef __ksr__
#define _POSIX_THREADS
#endif

I probably put that in around '93, but there are no more KSR machines
anymore -- that I know of.  I won't even make that change for 2.1 at this
late stage.

for-all-i-know-mac-os-x-#defines-__ksr__-ly y'rs  - tim