A possible bug in python threading/time module?
tim.one at comcast.net
Wed Jul 2 17:02:17 CEST 2003
> I've been running this segment of code (slightly simplified to
> emphasize the main part):
> ----START of Script----
> import time
> import threading
> sem = threading.Semaphore(2048)
> class MyThread(threading.Thread):
> def __init__(self):
> def run(self):
> j = 0
> for i in range(1000):
> j = j+1
> for i in range(4096):
> ----END of Script----
> I ran it on python 2.2.2 and python 2.3b1, and on both all of the
> threads started successfully, acquiring the semaphore until 0
> resources were left. However, about 10-20 threads remain active after
> a while (and the semaphore is lacking resources, respectively). I
> waited for about two hours, and nothing changed - it appears to be
> hanging. Did anyone encounter this behaviour before?
> Am I the only one who ran into this situation? Is this a bug?
If you run "enough" threads, chances are high you'll eventually run into a
platform thread bug on any platform -- but into different platform bugs on
different platforms. You didn't say which OS or platform thread library you
were using, and those are probably the only things that matter.
Here's a simplified and generalized minor rewrite of the above, with a
comment about what happens under Win2K and 2.3b2. I've got no interest in
chasing it down, since it's hung in the bowels of a Windows DLL and there's
no evidence of a Python bug:
# One thread hung at the end on Win2K at N == 2011.
# No problem if N < 2011.
N = 2011
sem = threading.Semaphore(N)
for i in range(2*N):
More information about the Python-list