On Jan 28, 2005, at 18:24, Martin v. Löwis wrote: >> 5. Many modules may not be thread safe (?). > Modules often release the GIL through BEGIN_ALLOW_THREADS, if they know > that would be safe if another thread would enter the Python > interpreter. Right, I guess that the modules already have to deal with being reentrant and thread-safe, since Python threads could already cause issues. >> Ignoring the issue of #5 for the moment, are there any other areas >> where this is a problem? I'm curious about how much work it would be >> to allow concurrent execution of Python code. > Define "concurrent". Webster's offers Sorry, I really meant *parallel* execution of Python code: Multiple threads simultaneously executing a Python program, potentially on different CPUs. > There have been attempts to implement free threading, and > they have failed. What I was trying to ask with my last email was what are the trouble areas? There are probably many that I am unaware of, due to my unfamiliarity the Python internals. > Due to some > unfortunate historical reasons, there is code which enters free() > without holding the GIL - and that is what the allocator specifically > deals with. Right, but as said in a previous post, I'm not convinced that the current implementation is completely correct anyway. > Again, the interpreter supports multi-threading today. Removing > the GIL is more difficult, though - nearly any container object > (list, dictionary, etc) would have to change, plus the reference > counting (which would have to grow atomic increment/decrement). Wouldn't it be up to the programmer to ensure that accesses to shared objects, like containers, are serialized? For example, with Java's collections, there are both synchronized and unsynchronized versions. Evan Jones
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