A possible bug in python threading/time module?

[Tim Peters]

[vm_usenet]
> 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):
        threading.Thread.__init__(self)
        sem.acquire()

    def run(self):
        time.sleep(5)
        sem.release()

for i in range(2*N):
    MyThread().start()
"""