2011/7/27 Charles-François Natali <neolo...@free.fr>: >>> I assume that ESHUTDOWN is the errno in question? (This is also already >>> mentioned in the PEP.) >> >> Indeed, I mentioned it in the PEP, as it appears in asyncore.py. >> But I can't find it on www.opengroup.org, and no man page on my Linux >> system (except the "errno" man page) seems to mention it. > > It's not POSIX, but it's defined on Linux and FreeBSD (at least): > http://lxr.free-electrons.com/source/include/asm-generic/errno.h#L81 > http://fxr.watson.org/fxr/source/sys/errno.h?v=FREEBSD53#L122 > >> The description from errnomodule.c says "Cannot send after transport >> endpoint shutdown", but send() actually returns EPIPE, not ESHUTDOWN, >> when the socket has been shutdown: > > Indeed, as required by POSIX. > > But grepping through the Linux kernel source code, it seems to be used > extensively for USB devices, see > http://lxr.free-electrons.com/ident?i=ESHUTDOWN > So the "transport endpoint" doesn't necessarily refer to a socket. > It's also documented in > http://lxr.free-electrons.com/source/Documentation/usb/error-codes.txt > > Finally, I found one place in the networking stack where ESHUTDOWN is > used, in the SCTP code: > http://lxr.free-electrons.com/source/net/sctp/outqueue.c#L329
Perhaps the right thing to do is to just have a ConnectionBrokenError that covers EPIPE, ESHUTDOWN and ECONNRESET? The current version of the PEP has these as two separate exception types (BrokenPipeError for the first two and ConnectionResetError for the last), but I'm not seeing a strong reason to avoid combining them. (ECONNABORTED and ECONNREFUSED are different, since they relate to failures when *initiating* a connection) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
