thread vs GC

Paul Rubin http
Thu Jun 2 20:50:06 EDT 2005


Another of those "how can I kill a thread" questions.

Let's say I have an app that needs a random prime number for something
every now and then, based on user interaction.  I have a function
makeprime() which creates such a prime, but it's pretty slow, so I
don't want to wait for it when the user clicks for a new prime.  I want
to generate some primes in the background and cache a few of them.  Let's
say I want to make an iterator object to wrap all this:

  class primegen:
    def __init__(self):
      self.q = Queue.Queue(5)    # cache up to 5 primes
      def background_generator():
         while True:
           self.q.put(makeprime())  # sleeps if 5 primes are already cached
      threading.Thread(target=background_generator).start()

    def next(self):
      return self.q.read()
    def __iter__(self): return self

Now I can make a caching prime stream with 

  g = primegen()

and it's all rather elegant.  But maybe g will sit in some other
object or for some other reason I end up making a bunch of these
generators.  The generators get cleaned up by GC when they go out of
scope, but the threads they spawn are left hanging around.

Adding a __del__ method that sets a flag (actually threading.Event)
which the background_generator function checks doesn't seem to do
the job.

Any suggestions for the cleanest way to get rid of the thread?  I can
think of some awful kludges that I'd rather not resort to.  

Extra points if it works in both Python and Jython, i.e. it isn't GIL
dependent.

Thanks for any ideas.



More information about the Python-list mailing list