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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4