On Nov 26, 2012, at 11:05 AM, Richard Oudkerk wrote:
> Using CancelIo()/CancelIoEx() to abort an operation started with WSARecv()
> does not seem to cause a problem
(emphasis mine)
Little command-line experiments are not the right way to verify the behavior of
high-performance I/O APIs. You
On 26/11/2012 11:49am, Kristján Valur Jónsson wrote:
However, other implementations of python sockets, e.g. ones that rely on
IO completion, may not have the luxury of using select. For example, on
Windows, there is no way to abort an IOCP socket call, so a timeout must
be implemented by abortin
If you're talking about the standard socket module, I'm not aware that
it uses IOCP on Windows. Are you asking this just in the abstract, or
do you know of a Python implementation that uses IOCP to implement the
standard socket type?
As to the design of the async I/O library (which I am still work
Hm. None of the distinctions brought up so far really hit true with me
(though they all are part of the picture). For example, I think the
distinction between type(x) and x.__class__ is rarely significant -- I
bet that if anyone were to rely on this they'd first have to change a
lot of code that us
Regarding the recent discussion on python-ideas about asyncronous IO, I'd like
to ask a question about python socket's Timeout feature.
Specifically this: Is it a documented or a guaranteed feature that a
send/receive operation that times out with a socket.timeout error is
re-startable on that
