On Thu, Apr 3, 2014 at 4:16 AM, Jonathan Slenders < [email protected]> wrote:
> By blocking, I meant "not progressing anymore". Not that is blocks the > thread. > > > Should we catch CancelledError here at this line? > https://code.google.com/p/tulip/source/browse/asyncio/base_events.py#410 > > Or use a finally block. There are probably some other places where we don't clean up when unexpected exceptions strike. This was a good catch, Jonathan! We should make sure this is fixed in as many places as possible before 3.4.1 goes out. > > Le jeudi 3 avril 2014 12:10:56 UTC+2, Victor Stinner a écrit : >> >> Hi, >> >> 2014-04-03 11:34 GMT+02:00 Jonathan Slenders <[email protected]>: >> > First he proposed to wrap create_connection into wait_for with a >> timeout=1 >> > parameter, but that would leave the file descriptor open that was >> created in >> > BaseEventLoop.create_connection(). Therefore he proposes to create >> the >> > socket ourself, using sock_connect , and if that fails due to a >> timeout, >> > call sock.close manually. >> >> When you use wait_for(), the coroutine gets a CancelledError and so >> can cleanup its data (close the socket). >> >> If create_connection() doesn't close the socket on error, it's a bug. >> Please open an issue. >> >> > How is it possible that loop.create_connection blocks? >> >> The slowest part is probably the DNS resolution. By default, >> getaddrinfo() is called in a thread. >> >> > Doesn't it just fail after a while if the host is not reachable? >> >> Network operations can be slow, but create_connection() should not >> "block", the coroutine should be running in background, as any "async" >> task. >> >> It would help to identify exactly which Python line hangs. >> >> Victor >> > -- --Guido van Rossum (python.org/~guido)
