A possible bug in python threading/time module?

Tim Peters 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):
>         threading.Thread.__init__(self)
>         sem.acquire()
>     def run(self):
>         j = 0
>         for i in range(1000):
>             j = j+1
>         time.sleep(60)
>         sem.release()
> #main
> for i in range(4096):
>     MyThread().start()
> ----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:

import time
import threading

# One thread hung at the end on Win2K at N == 2011.
# No problem if N < 2011.
N = 2011
sem = threading.Semaphore(N)

class MyThread(threading.Thread):
    def __init__(self):

    def run(self):

for i in range(2*N):

More information about the Python-list mailing list