Charles-François Natali <neolo...@free.fr> added the comment:
> That's true. Do you think temptatively acquiring the lock (without
> blocking) would solve the issue?
I think it should work. Something along those lines:
while True:
if lock.acquire(0):
lock.tstate = tstate
return True
else:
if detect_circularity():
return False
global_lock.release()
saved = save_tstate()
yield()
restore_tstate(saved)
global_lock.acquire()
However, I find this whole mechanism somewhat complicated, so the
question really is: what are we trying to solve?
If we just wan't to avoid deadlocks, a trylock with the global import
lock will do the trick.
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. But I'm not sure it's worth the extra
complexity (increasing the locking granularity is usually a proven
recipe to introduce deadlocks).
> Isn't this limit only about named semaphores? Or does it apply to
> anonymous semaphores as well?
I'm no FreeBSD expert, but AFAICT, POSIX SEM_NSEMS_MAX limit doesn't
seem to make a distinction between named and anonymous semaphores.
>From POSIX sem_init() man page:
"""
[ENOSPC]
A resource required to initialise the semaphore has been exhausted, or
the limit on semaphores (SEM_NSEMS_MAX) has been reached.
"""
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.
----------
_______________________________________
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
