Extension libraries, spawned threads, and the global interpreter lock

[Martin v. Loewis]

Damien Elmes <resolve at repose.REMOVE.cx> writes:

> So my question is: am I correct in thinking it's a problem with the GIL not
> being held in the other threads?

Probably not. Do the other threads ever call back into Python code, or
invoke Python interpreter API? If so, they need to hold the lock while
doing so. If they are completely separate, they are not concerned with
the GIL.

> If so, would explicitly grabbing and freeing the lock in the xlib
> threads solve the problem?

At what time would you free it? As long as one of the threads holds
the lock, your main thread will not advance.

More likely, you have a problem with signal handlers. Python installs
a SIGINT handler, to generate the KeyboardInterrupt. This can break
badly if the signal handler is not delivered to a Python thread, or
more specifically, to the main Python thread.

You have a number of choices: 

- don't install the SIGINT handler, but live with the default SIGINT
  processing (i.e. process termination)
- block SIGINT in the other threads. How to do this much depends on
  your operating system.
- find out why delivering the signal to another process causes a
  problem (it *may* be that you have to get the GIL inside 
  Modules/signalmodule.c:signal_handler; in theory, the current
  code is supposed to deal with this case, but perhaps it breaks
  for some reason, e.g. if getpid() returns the same value in all
  threads).

Regards,
Martin