On Aug 11, 2:16 pm, Paul Rubin <no.em...@nospam.invalid> wrote:
> EW <ericwoodwo...@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.
--
http://mail.python.org/mailman/listinfo/python-list
