Message150371
> 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. |
|
Date |
User |
Action |
Args |
2011-12-30 10:55:59 | neologix | set | recipients:
+ neologix, gvanrossum, brett.cannon, ncoghlan, belopolsky, pitrou, vstinner, christian.heimes, grahamd |
2011-12-30 10:55:58 | neologix | link | issue9260 messages |
2011-12-30 10:55:57 | neologix | create | |
|