Python has two GILs | Hacker News Reader

Python has two GILs

reticulatingsplines.posterous.com

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

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

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.

Reply on news.ycombinator.com