<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><span style="font-style: normal; ">There are definitely bugs </span><i>and</i> system-dependent behaviour* in these areas. Just a couple years ago I ran into one that lead to me writing a "handle_expt()" method with this comment before it: </div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><br></div><div style="color: rgb(0, 0, 0); font-variant: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><blockquote type="cite"><div><font face="Consolas"> #####</font></div><div><font face="Consolas"> # Semi-crazy method that is working around a sort-of bug within </font></div><div><font face="Consolas"> # asyncore. When using select-based I/O multiplexing, the POLLHUP </font></div><div><font face="Consolas"> # the socket state is indicated by the socket becoming readable, </font></div><div><font face="Consolas"> # and not by indicating an exceptional event.</font></div><div><font face="Consolas"> # </font></div><div><font face="Consolas"> # When using POLL instead, the flag returned indicates precisely </font></div><div><font face="Consolas"> # what the state is because "flags & select.POLLHUP" will be true.</font></div><div><font face="Consolas"> # </font></div><div><font face="Consolas"> # In the former case, when using select-based I/O multiplexing, </font></div><div><font face="Consolas"> # select's indication that the the descriptor has become readable </font></div><div><font face="Consolas"> # leads to the channel's handle read event method being invoked. </font></div><div><font face="Consolas"> # Invoking receive on the socket then returns an empty string, </font></div><div><font face="Consolas"> # which is taken by the channel as an indication that the socket </font></div><div><font face="Consolas"> # is no longer connected and the channel correctly shuts itself </font></div><div><font face="Consolas"> # down.</font></div><div><font face="Consolas"> # </font></div><div><font face="Consolas"> # However, asyncore's current implementation of the poll-based </font></div><div><font face="Consolas"> # I/O multiplex event handling invokes the channel's </font></div><div><font face="Consolas"> # handle exceptional data event anytime "flags & POLLHUP" is true. </font></div><div><font face="Consolas"> # While select-based multiplexing would only call this method when </font></div><div><font face="Consolas"> # OOB or urgent data was detected, it can now be called for POLLHUP </font></div><div><font face="Consolas"> # events too.</font></div><div><font face="Consolas"> # </font></div><div><font face="Consolas"> # Under most scenarios this is not problematic because poll-based </font></div><div><font face="Consolas"> # multiplexing also indicates the descriptor is readable and </font></div><div><font face="Consolas"> # so the handle read event is also called and therefore the </font></div><div><font face="Consolas"> # channel is properly close, with only an extraneous invocation </font></div><div><font face="Consolas"> # to handle exceptional event being a side-effect. Under certain </font></div><div><font face="Consolas"> # situations, however, the socket is not indicated as being </font></div><div><font face="Consolas"> # readable, only that it has had an exceptional data event. I </font></div><div><font face="Consolas"> # believe this occurs when the attemtp to connect never succeeds, </font></div><div><font face="Consolas"> # but a POLLHUP does. Previously this lead to a busy loop, which </font></div><div><font face="Consolas"> # is what this method fixes.</font></div><div><font face="Consolas"> ###</font></div></blockquote><div style="font-family: Helvetica; font-size: medium; font-weight: normal; "><div><br></div></div></div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><br></div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><br class="Apple-interchange-newline"><br class="Apple-interchange-newline"><br></div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><br></div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><br></div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">Shane Green </div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><a href="http://www.umbrellacode.com">www.umbrellacode.com</a></div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">805-452-9666 | <a href="mailto:shane@umbrellacode.com">shane@umbrellacode.com</a></div>
</div>
<br><div><div>On Oct 14, 2012, at 4:55 PM, Richard Oudkerk <<a href="mailto:shibturn@gmail.com">shibturn@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On 14/10/2012 11:45pm, Greg Ewing wrote:<br><blockquote type="cite">It does indeed contradict me. It looks like this is<br>implementation-dependent, because I distinctly remember<br>encountering a bug once that I traced back to the fact<br>that I wasn't servicing *all* the fds reported as ready<br>before making another select call.<br></blockquote><br>Could it have been that some fds were being starved because the earlier ones in the lists were getting priority? Servicing all fds reported prevents such starvation problems.<br><br><br>--<br>Richard<br><br>_______________________________________________<br>Python-ideas mailing list<br><a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>http://mail.python.org/mailman/listinfo/python-ideas<br></blockquote></div><br></body></html>