

Python has two GILs - famousactress
http://reticulatingsplines.posterous.com/python-has-two-gils

======
ch0wn
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.

~~~
sp332
GIL stands for both Global Interpreter Lock and Global Import Lock.

------
eurleif
So why can't importing a module block until the import lock can be acquired,
rather than throwing an exception?

~~~
famousactress
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 idea that deadlocks were a problem makes me think that this import lock
isn't exactly 'global', per-se.

~~~
sirclueless
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".

~~~
GauntletWizard
This is exactly the use case for Recursive Mutexes.

~~~
eurleif
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.

