ericwoodworth at gmail.com
Wed Aug 11 22:26:43 CEST 2010
On Aug 11, 2:52 pm, Paul Rubin <no.em... at nospam.invalid> wrote:
> EW <ericwoodwo... at gmail.com> writes:
> > 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.
> Even if GC worked that way it wouldn't matter, if you use just one queue
> per type of task. That number should be a small constant so the memory
> consumption is small.
Well I can't really explain it but 1 Queue per task for what I'm
designing just doesn't feel right to me. It feels like it will lack
future flexibility. I like having 1 Queue per producer thread object
and the person instantiating that object can do whatever he wants with
that Queue. I can't prove I'll need that level of flexibility but I
don't see why it' bad to have. It's still a small number of Queues,
it's just a small, variable, number of Queues.
More information about the Python-list