Python Interpreter Reentrancy?
Mark Hammond
MarkH at ActiveState.com
Sun Apr 22 19:06:35 EDT 2001
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.
More information about the Python-list
mailing list