Queue cleanup

EW ericwoodworth at gmail.com
Wed Aug 11 20:39:10 CEST 2010

On Aug 11, 2:16 pm, Paul Rubin <no.em... at nospam.invalid> wrote:
> EW <ericwoodwo... at gmail.com> writes:
> > I thought about doing it that way and I could do it that way but it
> > still seems like there should be a way to clean up Queues on my own.
> > If I did it this way then I guess I'd be relying on garbage collection
> > when the script ended to clean up the Queues for me.
> Oh, I see.  As long as it's possible to start new producer or consumer
> threads that touch a queue, obviously that queue has to still be around.
> If the program starts all its threads at the beginning, then runs til
> they exit, then does more stuff, then you could do something like:
>     # make dictonary of queues, one queue per task type
>     queues = {'sql': Queue(), 'logging': Queue(), ... }
>     for i in <whatever threads you want>
>        threading.Thread(target=your_handler, args=[queues])
>     del queues
> and then when all the threads exit, there are no remaining references to
> the queues.  But why do you care?  Queues aren't gigantic structures,
> they're just a list (collections.deque) with an rlock.  It's fine to let
> the gc clean them up; that's the whole point of having a gc in the first
> place.

Well I cared because I thought garbage collection would only happen
when the script ended - the entire script.  Since I plan on running
this as a service it'll run for months at a time without ending.  So I
thought I was going to have heaps of Queues hanging out in memory,
unreferenced and unloved.  It seemed like bad practice so I wanted to
get out ahead of it.

But the GC doesn't work the way I thought it worked so there's really
no problem I guess. I was just confused on garbage collection it seems.

More information about the Python-list mailing list