threads or queue for this task
James J. Besemer
jb at cascade-sys.com
Sun Sep 15 03:46:55 EDT 2002
robin at execulink.com wrote:
>Er, quite. For some reason I had not thought of simply having the
>worker threads look for work. I was thinking more in terms of a Queue,
>where the workers are fed work. But this is likely not even needed.
>In my case I would have them loop indefinitely. Something simple like:
>nap = 1
> except MyInterrupt:
>Having individual threads sleeping will not adversely effect
>performance I imagine.
In general I would say it's not a problem. So long as they're sleeping,
they're not making any significant demands on the system.
On the other hand, you probably DO want to eliminate explicit sleeps
like this if you can. E.g., the sleeps force a delay if data arrives to
be processed during the sleep. Or even if data arrives while processing
the current command -- instead of immediately going on to the next
command, the thread doesn't even look for the next command until after
it takes a manditory nap, which in most cases you don't want..
If you are clever, proper design of LookForWork() can automatically
suspend the threads when they have nothing to do. E.g., that's one of
the great features of using a Queue -- threads are put to sleep if they
read an empty queue and they are woken up automatically when something
it put into the queue. Similarly, if your thread is reading a Socket()
-- it'll sleep until data is available. Then you don't need the
James J. Besemer 503-280-0838 voice
2727 NE Skidmore St. 503-280-0375 fax
Portland, Oregon 97211-6557 mailto:jb at cascade-sys.com
More information about the Python-list