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 neologix
Recipients giampaolo.rodola, gvanrossum, jcea, neologix, pitrou, sbt, trent
Date 2013-01-22.19:04:07
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
> 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 receiving
side, it will get truncated is the buffer is too small.

Going back to the subject: so what do we say, let's just forget about
supporting WSAPoll at all (both in CPython and tulip)?

If we ever choose to export it, I think the least we should do would
be to not export it as select.poll(): since it has - not so subtle -
semantic differences with poll(), code using previously select() on
Windows may silently break when poll() is suddenly available: e.g.
asyncore with use_poll=True would probably deadlock in case of
unreachable host, if WSAPoll doesn't report connect() failures.

When I see the hoops Richard had to go through to make WSAPoll usable
in tulip, my gut feeling is that exposing it wouldn't be making a
favor to poor unsuspecting Windows programmers :-\
Date User Action Args
2013-01-22 19:04:08neologixsetrecipients: + neologix, gvanrossum, jcea, pitrou, giampaolo.rodola, trent, sbt
2013-01-22 19:04:08neologixlinkissue16507 messages
2013-01-22 19:04:07neologixcreate