Showing content from http://mail.python.org/pipermail/python-dev/attachments/20071213/ab17deba/attachment.htm below:
<br><div><span class="gmail_quote">On 12/12/07, <b class="gmail_sendername">Guido van Rossum</b> <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Dec 12, 2007 2:42 PM, Greg Ewing <<a href="mailto:greg.ewing@canterbury.ac.nz">greg.ewing@canterbury.ac.nz</a>> wrote:<br>> But there's no excuse for using CPU when the application<br>> truly isn't doing anything other than waiting for
<br>> something to happen.<br><br>There are tons of situations where polling is quite reasonable as logn<br>as it involves a sleep.</blockquote><div><br>Now that I have to disagree with, possibly because sleep is ambiguous as stated. Periodic time based polling means your APIs are broken (not that one often has control over what APIs are available). Blocking only to be woken up when any of the events your interested in is always best. If you have periodic tasks that must be performed then obviously an event you're interested in is "time T or X time has passed" but that is distinct from a process waking up regularly to check the empty work queue length only to sleep again.
<br><br>Regardless this thread already resolved the issue with an acceptable solution (yay!) so further discussion is merely a bike shed.<br><br>-gps<br></div></div>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4