Python Interpreter Reentrancy?

[Mark Hammond]

Courageous wrote:

>>I'm not quite sure what you're asking for.  It's certainly the case that


>>multiple threads in a C application can call Python code, but each time
>>you call into Python, you need to acquire the GIL first (along with first
>>making sure that you've done all the proper initialization). 
>>
> 
> I'm asking for a reentrant Python interpreter -- one in which a global
> interpreter lock isn't necessary. Clearly that's not around yet.


That is no problem.  Python does this fine, and COM/XPCOM in particular 
rely on this feature.

  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.

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.

Mark.