peter at engcorp.com
Thu Mar 7 02:07:59 CET 2002
Cliff Wells wrote:
> On Wed, 6 Mar 2002 13:26:12 -0800
> Cliff Wells wrote:
> > The approach I would take, based upon the information given, is to have
> > thread A retrieve the data every .1s (using time.sleep), when the data
> > retrieved, put it on a Queue and go back to sleep. Thread B blocks on
> > Queue until data is available. When data becomes available, B processes
> > that data and place it on a second Queue for thread C (thread C handling
> > HTTP requests) to deal with.
> Hm. Okay, I had to reconsider this. Clearly if the processing is slower
> than .1s and data is being added to it every .1s, the Queue is going to
> endlessly grow as more data is added to it. If this is the case, it might
> make sense to have more than one consumer thread (B) doing the processing.
I might be missing something, but I don't see how adding another thread
(with a slight extra overhead associated with it) would actually increase
performance for what I infer is CPU-bound processing in thread B.
Threads don't add performance capacity, they remove it! (Or is B blocking
on something like a socket, thus slowing it down?)
More information about the Python-list