Python Interpreter Reentrancy?

[Tim Peters]

[Mark Hammond]
> ...
> The problem you will strike is the lack of portable thread-local-
> storage.  However, see the CEnterLeavePython class in pywintypes.h
> for an implementation using MS TLS and pyxpcom.h that uses
> Netscape Portable Runtime (NSPR) abstractions from Mozilla for TLS.
>
>   Python can only provide this level of support if it moves the thread
> barrier that little bit higher.  Many people believe that most modern
> threading libraries are capable, but requiring all python platforms
> provide TLS and other more advanced threading concepts before they can
> use threads is a fair bit of work.

I expect Guido is dead tired of this, not least because I am and I can poison
his mind at times without him realizing it <wink>.  We've bounced this idea
back and forth a few times:  PythonLabs supports threads on standard POSIX
pthreads systems and Windows boxes, and that's it.  Support on any other
platform requires an expert from that platform to step up and volunteer the
ongoing work it needs to keep it healthy, but the Python distribution doesn't
guarantee anything about it.  Lose the platform expert, and bugs will be
closed with "sorry, your platform is no longer loved".

This is very cruel, eh?  I'm afraid it's also very practical:  since threads
are not-- and never will be --part of standard C, making them work slick
across platforms is a bloody nightmare.  For years, Python's thread story has
been choked down to the feeblest of all platforms anyone ever contributed a
half-baked thread implementation for.

> Actually, I wonder if the NSPR could help out here?  For more obscure
> platforms, we could provide an option that allows Python to use the
> NSPR for it's thread support.

PythonLabs doesn't have the bandwidth to play with yet another unique thread
package, but if someone else can volunteer to whip that into shape, it's
better than telling oddball-platform users "screw you" <wink>.

raging-against-the-threads-ly y'rs  - tim