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 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 :-\ ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16507> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
