issues in: 909005 and 17361001, as well as completely as possible issues
539444, 760475, 777588, 889153, 953599, 1025525, 1063924, and 658749.
This patch also includes doc and test updates as necessary.
of the dispatcher object break. e.g. if you close() the object, it
tries to remove itself from the default map, not from the map the
dispatcher was created with.
The patch, from Stephane Ninin, records the map as an attribute of
the dispatcher instance.
2.3 bugfix candidate.
blocked in select(), this will raise select.error with errno set to
EINTR. The except clauses correctly ignores this error, but the rest
of the logic will then call read() for all objects in select's *input*
list of read file descriptors. Then when an object's read_handler()
is naive, it will call recv() on its socket, which will raise an
IOError, and then asyncore decides to close the socket. To fix this,
we simply return in this case.
Backport candidate.
routines. I got some errors "dictionary changed size during
iteration" when running ZEO tests on machine while doing heavy
forground work in another window, and thinking about it, I believe
that it should be okay if readable() or writable() modifies the map.
I also finally made all the spacing conform to the Python style guide:
no space between a function/method name and the following left
parenthesis (fixed lots of occurrences), spaces around assignment
operators (fixed a few, always of the form "map=..."), and a blank
line between the class statement and the first method definition (a
few).
Add read(), write(), and readwrite() helper functions to shorten poll
functions. Use get() instead of try/except KeyError for lookup.
XXX How could the lookup ever fail?
Remove module-level DEBUG flag.
Use iteritems() instead of items() when walking the socket map.
Reformat the functions I touched so that are consistently Pythonic.
asyncore.poll, the select fails with EINTR, which the
code catches. However, the code fails to clear the
r/w/e arrays (like poll3 does), which means it acts as
if every descriptor had received all possible events.
Bug report and patch by Cesar Eduardo Barros
Rev 1.20 introduced a call to getpeername() in the dispatcher
constructor. This only works for a connected socket. Apparently
earlier versions of the code worked with un-connected sockets, e.g. a
listening socket.
It's not clear that the code is supposed to accept these sockets,
because it sets self.connected = 1 when passed a socket. But it's
also not clear that it should be a fatal error to pass a listening
socket.
The solution, for now, is to put a try/except around the getpeername()
call and continue if it fails. The self.addr attribute is used
primarily (only?) to produce a nice repr for the object, so it hardly
matters. If there is a real error on a connected socket, it's likely
that subsequent calls will fail too.
Josiah Carlson
Brett Cannon
Georg Brandl
Neal Norwitz
Andrew M. Kuchling
Tim Peters
Michael W. Hudson
Martin v. Löwis
Raymond Hettinger
Walter Dörwald
Guido van Rossum
Thomas Heller
Jeremy Hylton