threads or queue for this task

[James J. Besemer]

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
>while 1:
>    try:
>        LookForWork()
>		time.sleep(nap)
>	except MyInterrupt:
>		break
>	except:
>		raise
>
>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 
explicit sleeps.

Regards

--jb

-- 
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
				http://cascade-sys.com