> If, on the other hand, we really want to reduce the number of cases
> where a deadlock would occur by increasing the locking granularity,
> then it's the way to go.

Yes, that's the point. Today you have to be careful when mixing imports
and threads. The problems is that imports can be implicit, inside a
library call for example (and putting imports inside functions is a way
of avoiding circular imports, or can also allow to reduce startup time).
Some C functions try to circumvent the problem by calling
PyImport_ModuleNoBlock, which is ugly and fragile in its own way (it
will fail if the import lock is taken, even if there wouldn't be a
deadlock: a very primitive kind of deadlock avoidance indeed).

> Also, a quick search returned those links:
> http://ftp.es.freebsd.org/pub/FreeBSD/development/FreeBSD-CVS/src/sys/sys/ksem.h,v
> http://translate.google.fr/translate?hl=fr&sl=ru&tl=en&u=http%3A%2F%2Fforum.nginx.org%2Fread.php%3F21%2C202865%2C202865
> So it seems that sem_init() can fail when the max number of semaphores
> is reached.

As they say, "Kritirii choice of the number 30 in the XXI century is
unclear." :-)

File objects also have a per-object lock, so I guess opening 30 files
under FreeBSD would fail. Perhaps we need to fallback on the other lock
implementation on certain platforms?

(our FreeBSD 8.2 buildbot looks pretty much stable, was the number of
semaphores tweaked on it?)