Antoine Pitrou <pit...@free.fr> added the comment: > 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?) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9260> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
