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 martin.panter
Recipients martin.panter, palaviv
Date 2016-02-19.22:41:38
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1455921698.98.0.562564478128.issue26392@psf.upfronthosting.co.za>
In-reply-to
Content
I thought the purpose of server_close() was to clean up resources after you have finished calling serve_forever() or handle_request(). Just like you call close() on a file after you have finished reading or writing it. If you try to read or write a closed file, that is a programmer error.

This proposal sounds like a new feature, but you are overloading or redefining the purpose of server_close().

From the test case I presume you intend to use server_close() in a separate thread from the thread running serve_forever(). But closing a file descriptor while it is being used in another thread does not seem robust to me. It could cause serve_forever() to raise EBADF. In the worst case, consider what happens if an unrelated third thread makes the server’s file descriptor valid again by opening a file.

What is your use case? If you want to use multithreading, why can’t you use the shutdown() method? For a single-threaded server, maybe see Issue 13749, and maybe Issue 23430 would help by allowing exceptions like SystemExit to stop the server.
History
Date User Action Args
2016-02-19 22:41:39martin.pantersetrecipients: + martin.panter, palaviv
2016-02-19 22:41:38martin.pantersetmessageid: <1455921698.98.0.562564478128.issue26392@psf.upfronthosting.co.za>
2016-02-19 22:41:38martin.panterlinkissue26392 messages
2016-02-19 22:41:38martin.pantercreate