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 <CAH_1eM0iSpekRncddt5ZyUuRQbfP1N=0C7v99Lx4UDn305A83g@mail.gmail.com>
In-reply-to <1358874542.87.0.523200241296.issue16507@psf.upfronthosting.co.za>
Content
> 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 :-\
History
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