This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author giampaolo.rodola
Recipients MrJean1, alanmcintyre, donmez, facundobatista, giampaolo.rodola, josiahcarlson, mark.dickinson, r.david.murray
Date 2009-05-08.22:20:03
SpamBayes Score 1.48569e-10
Marked as misclassified No
Message-id <>
Even if that patch would fix this issue (and I'm pretty sure it does) I
don't think it's a good idea handling all those errors (EBADF,

Although those error codes unmistakably remark a disconnect event
condition (EBADF too? are we sure it *always* means that?) I would
prefer that be done in asyncore.dispatcher() and handle_close() be
called from there.

That's the implementation asyncore has always used until now where the
poller logic (poll(), poll2()) has always been kept separated from the
connection logic (asyncore.dispatcher) where the "if socket.err[0] in
..." stuff is done.

Unfortunately I haven't got an OS X box to test against and verify by
myself, but If I'm not mistaken by looking at the traceback messages
pasted by other folks, it seems that the exception takes place in
handle_expt_event() at this point:

err = self.socket.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR)

If that's the case I think it makes more sense catching EBADF from there
rather than breaking the logic used so far, also because, if I'm not
mistaken, the problem has been introduced by this very line which has
been added in Python 2.6.
Date User Action Args
2009-05-08 22:20:05giampaolo.rodolasetrecipients: + giampaolo.rodola, facundobatista, josiahcarlson, mark.dickinson, alanmcintyre, donmez, MrJean1, r.david.murray
2009-05-08 22:20:05giampaolo.rodolasetmessageid: <>
2009-05-08 22:20:04giampaolo.rodolalinkissue5798 messages
2009-05-08 22:20:03giampaolo.rodolacreate