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 forest
Recipients forest
Date 2008-12-18.00:31:59
SpamBayes Score 0.0
Marked as misclassified No
Message-id <>
With use_poll=True on linux, asyncore calls handle_write() after the
socket has been closed.

More specifically, it looks like asyncore dispatches handle_read() and
handle_close() events between the writable() test and the corresponding
handle_write() call.  If handle_close() calls close(), as asyncore's
default implementation does, the subsequent handle_write() will fail and
generate an EBADF (bad file descriptor) exception.  If handle_error()
also calls close(), as asyncore's default implementation does, this will
mean close() gets called twice on the same socket.

I am attaching example code which demonstrates the problem on Linux
2.6.24 using python 2.5.2, 2.5.3rc1, and 2.6.  In one window, run  In another window, establish a TCP connection to port
12345 and immediately close it without reading or writing.  This can be
done from within the python interactive interpreter like this:

  import socket
  s=socket.socket( socket.AF_INET, socket.SOCK_STREAM); s.connect(
    ('localhost', 12345)); s.close()

The output from will look like this:

  writable() - asyncore asked if we have data to write
  handle_read() - asyncore asked us to read
  handle_close() - asyncore said the remote host closed connection
  close() - we are closing our end of the connection
  handle_write() - asyncore asked us to write
  handle_error() - asyncore exception: (9, 'Bad file descriptor')
  close() - we are closing our end of the connection

IMHO, two things need fixing here:

1. When writable() returns True, the next handler asyncore calls should
be handle_write().  Calling other handlers in between risks invalidating
the writable() return value.

2. After close(), asyncore should not call handle_write(), even if
writable() would return true.
Date User Action Args
2008-12-18 00:32:02forestsetrecipients: + forest
2008-12-18 00:32:02forestsetmessageid: <>
2008-12-18 00:32:01forestlinkissue4690 messages
2008-12-18 00:32:00forestcreate