Python has two GILs(reticulatingsplines.posterous.com)
reticulatingsplines.posterous.com
Python has two GILs
http://reticulatingsplines.posterous.com/python-has-two-gils
2 comments
I'm not an expert in CPython's internals either, but import lock does not need to equal global interpreter lock. I do agree though, that this behavior isn't intuitive at all.
GIL stands for both Global Interpreter Lock and Global Import Lock.
Yeah, obviously two totally different things. Just a cheeky title since I found it humorous that they both ended up with the same acronyms and the GIL at this point is well understood/feared/discussed while this import lock is something that I hadn't ever heard of.
So why can't importing a module block until the import lock can be acquired, rather than throwing an exception?
I don't completely understand that either. This comment from the ticket that originated the behavior ( http://bugs.python.org/issue1567 ) comes with the following explanation:
It fixes several issues related to dead locks when a thread uses a
function that imports a module but another thread holds the lock. It
doesn't require static caching of modules.
The thing about Python is that it is a scripting language. Importing a Python module involves executing arbitrary code.
Here is a quick rundown of how a deadlock can occur:
1. The main module runs in Thread #1, which imports module "foo".
2. Module "foo" has code at the top level that starts a new thread (Thread #2), and then blocks waiting for it to do something.
3. In Thread #2, someone calls datetime.strptime(). This deadlocks because now Thread #2 needs to import "_strptime" but Thread #1 holds the Global Import Lock because it is importing "foo".
Here is a quick rundown of how a deadlock can occur:
1. The main module runs in Thread #1, which imports module "foo".
2. Module "foo" has code at the top level that starts a new thread (Thread #2), and then blocks waiting for it to do something.
3. In Thread #2, someone calls datetime.strptime(). This deadlocks because now Thread #2 needs to import "_strptime" but Thread #1 holds the Global Import Lock because it is importing "foo".
This is exactly the use case for Recursive Mutexes.
I don't think so. It sounds like this is about one thread trying to acquire the lock while another holds it, not the same thread trying to acquire the same lock twice.