homepage

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.

classification
Title: asyncore does not check for POLLERR and POLLHUP if neither readable nor writable
Type: behavior Stage:
Components: IO, Library (Lib) Versions: Python 3.1, Python 3.4, Python 3.5
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: BreamoreBoy, giampaolo.rodola, socketpair, vstinner
Priority: normal Keywords:

Created on 2011年02月21日 05:54 by socketpair, last changed 2022年04月11日 14:57 by admin. This issue is now closed.

Messages (3)
msg128941 - (view) Author: Марк Коренберг (socketpair) * Date: 2011年02月21日 05:54
asyncore.py: poll2() :
--------------------
if flags:
 # Only check for exceptions if object was either readable
 # or writable.
 flags |= select.POLLERR | select.POLLHUP | select.POLLNVAL
 pollster.register(fd, flags)
--------------------
This is unexpected behaviour. Why descriptor does not get polled if neither read nor write selected ? So I can not track dropping of connection if I do not want neither read nor write. I think "if flags:" should be removed.
msg220903 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2014年06月17日 21:57
I'm assuming that any work on this is unlikely as asyncore is deprecated in favour of asyncio.
msg225999 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2014年08月27日 16:29
> Why descriptor does not get polled if neither read nor write selected ?
IMO it's a deliberate design choice, made for performances.
In the asyncio module, the high-level StreamReader API stops listening to read even if the buffer is too large (if we received more than limit*2 bytes, where limit is 64 KB by default). We listen again when the application reads enough data from the buffer.
When we stop listening to read event (and we don't listen to write events neither), we ignore completly the socket. So if the socket is closed, we are not notified immediatly. IMO it's a design choice for efficency. It's more efficient to ignore temporarily the socket while the application is busy, than notifying immediatly that the connection was closed.
In my test, I still got some bytes with socket.recv() even after the connection was already closed by the peer.
Pseudo-code:
- client: connect
- client: recv(10): get some bytes
- server: close the connection
- client: recv(10): get more bytes (even if the connection was already closed)
- client: notified that the connection was closed
I don't think that asyncore nor asyncio should be modified to be notified immediatly that a connection was closed, so I close the issue.
Thanks for your report, it was an interesting question :-)
History
Date User Action Args
2022年04月11日 14:57:13adminsetgithub: 55476
2014年08月27日 16:29:53vstinnersetstatus: open -> closed

nosy: + vstinner
messages: + msg225999

resolution: not a bug
2014年06月17日 21:57:17BreamoreBoysetnosy: + BreamoreBoy, giampaolo.rodola

messages: + msg220903
versions: + Python 3.4, Python 3.5, - Python 2.6, Python 2.7, Python 3.2, Python 3.3
2011年02月21日 05:54:31socketpaircreate

AltStyle によって変換されたページ (->オリジナル) /