Changes by Richard Oudkerk shibt...@gmail.com:
--
keywords: +gsoc -patch
resolution: - rejected
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16507
Richard Oudkerk added the comment:
It appears that Linux's spurious readiness notifications are a deliberate
deviation from the POSIX standard. (They are mentioned in the BUGS section of
the man page for select.)
Should I just apply the following patch to the default branch?
diff -r
Charles-François Natali added the comment:
It appears that Linux's spurious readiness notifications are a deliberate
deviation from the POSIX standard. (They are mentioned in the BUGS section
of the man page for select.)
I don't think it's a deliberate deviation, but really
Antoine Pitrou added the comment:
Also, in real code you have to be prepared to catch EAGAIN regardless
of spurious notifications: when a FD is reported as read ready, it
just means that there are some data to read. Depending on the
watermark, it could mean that only one byte is available.
Richard Oudkerk added the comment:
According to Alan Cox
It's a design decision and a huge performance win. It's one of the areas
where POSIX read in its strictest form cripples your performance.
See https://lkml.org/lkml/2011/6/18/103
(For write ready, you can obviously have
Charles-François Natali added the comment:
If only one byte is available, recv(4096) should simply return a partial
result.
Of course, but how do you know if there's data left to read without
calling select() again? It's much better to call read() until you get
EAGAIN than calling select()
Charles-François Natali added the comment:
For SOCK_STREAM, yes, not for SOCK_DGRAM (or for a pipe when trying to
write more than PIPE_BUF, although I guess any sensible implementation
doesn't report the pipe write ready if there's less than PIPE_BUF
space left).
That should be of course
Guido van Rossum added the comment:
Short reads/writes are orthogonal to EAGAIN. All the mainline code treats
readiness as a hint only, so tests should too.
--Guido van Rossum (sent from Android phone)
--
___
Python tracker rep...@bugs.python.org
Richard Oudkerk added the comment:
For SOCK_STREAM, yes, not for SOCK_DGRAM
I thought SOCK_DGRAM messages just got truncated at the receiving end.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16507
Charles-François Natali added the comment:
I thought SOCK_DGRAM messages just got truncated at the receiving end.
You were referring to partial writes: for a datagram-oriented
protocol, if the datagram can't be sent atomically (in one
send()/write() call), the kernel will return EAGAIN. On the
Guido van Rossum added the comment:
Agreed, it does not sound very useful to support WSAPoll(), neither in
selector.py (which is intended to eventually be turned into
stdlib/select.py) nor in PEP 3156. And then, what other use is there
for it, really?
--
Guido van Rossum added the comment:
This is a very good question to which I have no good answer. If it weren't for
this, we could probably do away with the distinction between add_writer and
add_connector, and a lot of code could be simpler. (Or is that distinction
also needed for IOCP?)
Richard Oudkerk added the comment:
On 21/01/2013 5:38pm, Guido van Rossum wrote:
This is a very good question to which I have no good answer.
If it weren't for this, we could probably do away with the distinction
between add_writer and add_connector, and a lot of code could be
simpler. (Or
Guido van Rossum added the comment:
Thanks -- I am now close to rejecting the WSAPoll() patch, and even
closer to rejecting its use for Tulip on Windows. That would in turn
mean that we should kill add/remove_connector() and also the
EVENT_CONNECT flag in selector.py. Anyone not in favor please
Richard Oudkerk added the comment:
On 21/01/2013 7:00pm, Guido van Rossum wrote:
Regarding your IOCP changes, that sounds pretty exciting. Richard,
could you check those into the Tulip as a branch? (Maybe a new branch
named 'iocp'.)
OK. It may take me a while to rebase them.
--
Richard Oudkerk added the comment:
I have created an iocp branch.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16507
___
___
Python-bugs-list
Charles-François Natali added the comment:
I have created an iocp branch.
You could probably report the fixes for spurious notifications in the
default branch.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16507
Guido van Rossum added the comment:
Oh, it needs a new patch -- the patch fails to apply in the 3.4
(default) branch.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16507
___
Guido van Rossum added the comment:
Here's a new version of the patch. (Will test on Windows next.)
--
Added file: http://bugs.python.org/file28799/runtime_wsapoll.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16507
Guido van Rossum added the comment:
That compiles (after hacking the line endings). One Tulip test fails,
PollEventLooptests.testSockClientFail. But that's probably because the
PollSelector class hasn't been adjusted for Windows yet (need to dig this out
of the Pollster code that was
Guido van Rossum added the comment:
That compiles (after hacking the line endings). One Tulip test fails,
PollEventLooptests.testSockClientFail. But that's probably because the
PollSelector class hasn't been adjusted for Windows yet (need to dig this out
of the Pollster code that was
Richard Oudkerk added the comment:
That compiles (after hacking the line endings). One Tulip test fails,
PollEventLooptests.testSockClientFail. But that's probably because the
PollSelector class hasn't been adjusted for Windows yet (need to dig this
out of the Pollster code that was
Guido van Rossum added the comment:
Ow. How painful. I'll leave this for you to do. Note that this also
requires separating EVENT_WRITE from EVENT_CONNECT -- I am looking
into this now, but I am not sure how far I will get with this.
--
___
Python
Guido van Rossum added the comment:
(FWIW, I've got the EVENT_CONNECT separation done.)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16507
___
Charles-François Natali added the comment:
Time for a stupid question from someone who doesn't know anything about
Windows: if WSAPoll() is really terminally broken, is it really worth the
hassle exposing it and warping the API?
AFAICT, FD_SETSIZE is already bumped to 512 on Windows, and
Guido van Rossum added the comment:
This works well enough (tested in old version of Tulip), right? What's holding
it up?
--
nosy: +gvanrossum
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16507
Richard Oudkerk added the comment:
Here is a new version with tests and docs.
Note that the docs do not mention the bug mentioned in
http://daniel.haxx.se/blog/2012/10/10/wsapoll-is-broken/
Maybe they should?
Note that that bug makes it a bit difficult to use poll with tulip on Windows.
Richard Oudkerk added the comment:
It seems that the return code of WSAPoll() does not include the count of array
items with revents == POLLNVAL. In the case where all of them are POLLNVAL,
instead of returning 0 (which usually indicates a timeout) it returns -1 and
WSAGetLastError() ==
Richard Oudkerk added the comment:
Here is a version which loads WSAPoll at runtime. Still no tests or docs.
--
Added file: http://bugs.python.org/file28207/runtime_wsapoll.patch
___
Python tracker rep...@bugs.python.org
Richard Oudkerk added the comment:
Attached is an alternative patch which only touches selectmodule.c. It still
does not support WinXP.
Note that in this version register() and modify() do not ignore the POLLPRI
flag if it was *explicitly* passed. But I am not sure how best to deal with
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16507
___
___
Changes by Jesús Cea Avión j...@jcea.es:
--
nosy: +jcea
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16507
___
___
Python-bugs-list mailing list
Trent Nelson added the comment:
On Sun, Nov 18, 2012 at 03:19:19PM -0800, Antoine Pitrou wrote:
Antoine Pitrou added the comment:
Related post:
http://daniel.haxx.se/blog/2012/10/10/wsapoll-is-broken/
Yeah, came across that yesterday. Few other relevant links, for the
records:
New submission from Trent Nelson:
Attached patch adds select.poll() support on Windows via WSAPoll.
It's hacky; I was curious to see whether or not it could be done, and whether
or not tulip's pollster would work with it.
It compiles and works, but doesn't play very nicely with tulip. Also,
Antoine Pitrou added the comment:
Related post:
http://daniel.haxx.se/blog/2012/10/10/wsapoll-is-broken/
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16507
___
35 matches
Mail list logo
