gh-110038: KqueueSelector must count all read/write events#110039
gh-110038: KqueueSelector must count all read/write events#110039vstinner merged 3 commits intopython:mainfrom
Conversation
| result = s.select() | ||
| # We get the read and write either in the same result entry or in two | ||
| # distinct entries with the same key. | ||
| self.assertLessEqual(len(result), 2) |
There was a problem hiding this comment.
I suggest to move this check at the end, and make sure that len == 2.
There was a problem hiding this comment.
We might get 1 or 2 items, depending on the implementation. I think it's only 2 for KqueueSelector (which is not ideal, but see note in the PR).
There was a problem hiding this comment.
Oh, it's possible that a single entry contains both events, I see! Ok.
|
Thanks for the test! |
|
Sorry, @sorcio and @vstinner, I could not cleanly backport this to |
|
Sorry, @sorcio and @vstinner, I could not cleanly backport this to |
…ts (pythonGH-110039). (cherry picked from commit b14f0ab) Co-authored-by: Davide Rizzo <sorcio@gmail.com>
|
GH-110043 is a backport of this pull request to the 3.12 branch. |
|
GH-110044 is a backport of this pull request to the 3.11 branch. |
…ts (pythonGH-110039). (cherry picked from commit b14f0ab) Co-authored-by: Davide Rizzo <sorcio@gmail.com>
|
With this change, each registered read or write filter is counted separately, even if it shares a fd.
As a side effect, a call to
KqueueSelector.select()might return a separate entry with the same key, one with EVENT_READ and the other with EVENT_WRITE (and never both). This was already the case before, but it might become more evident now.KqueueSelectormiscounts max events #110038