This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients alex, christian.heimes, dstufft, janssen, martin.panter, pitrou, vstinner
Date 2017-07-04.12:06:51
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <a1a2ef44-6af1-12da-7c1c-ce77a52e7da0@free.fr>
In-reply-to <1499169613.95.0.76220362253.issue30319@psf.upfronthosting.co.za>
Content
Le 04/07/2017 à 14:00, STINNER Victor a écrit :
> 
> Antoine Pitrou: "shutdown() is not the same thing as close()."
> 
> I consider that the bug is similar to socket.close() error,
> [...]

First, let's not call it a bug when an error is reported to the user.  A
bug would be to silence all errors just because they annoy one core
developer.

Second, close() and shutdown() are different functions operating at
different levels.  close() operates at the OS level and releases
resources associated with the given file descriptor.  It might, but
might not, do any I/O (such as flush buffers or send a TCP RST) -- for
example, if you duplicated a fd after fork(), calling close() on only
one of them will do absolutely nothing at the I/O level.

shutdown() operates at the transport level.  Someone who calls
shutdown() *must* be notified that the shutdown went wrong, because
that's the only thing shutdown() does.  shutdown() does nothing at the
OS level.

It makes sense to silence some errors in close() because, most of the
time, people call close() to release resources and they don't care
whether the other end of the connection was notified in time.  It
doesn't make sense to do the same for shutdown().
History
Date User Action Args
2017-07-04 12:06:52pitrousetrecipients: + pitrou, janssen, vstinner, christian.heimes, alex, martin.panter, dstufft
2017-07-04 12:06:52pitroulinkissue30319 messages
2017-07-04 12:06:51pitroucreate