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 Arcege, giampaolo.rodola, martin.panter, neologix, petri.lehtinen, pitrou, santoso.wijaya, socketpair, tshepang
Date 2016-02-11.03:26:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1455161200.37.0.956225076159.issue12463@psf.upfronthosting.co.za>
In-reply-to
Content
Michael’s patch looks like it adds some backwards compatibility problems. The forking server overwrites a signal handler, and shutdown() no longer seems to wait at all.

It seems that people want shutdown() to do different things. Mark doesn’t want it to wait for the server in case an exception stops serve_forever() from starting its loop. So he has to rely on join() rather than just shutdown() to ensure that serve_forever() will no longer run.

Antoine wants shutdown() to guarantee that serve_forever() has stopped. So he has to hope that no exception (e.g. KeyboardInterrupt) prevents serve_forever() from starting. I think I agree with this. If you want to do extra processing before calling serve_forever(), maybe use an exception handler, different thread, or synchronization mechanism to avoid the lockout problem instead. I suggest just documenting the way things work and leaving it at that.
History
Date User Action Args
2016-02-11 03:26:40martin.pantersetrecipients: + martin.panter, pitrou, giampaolo.rodola, neologix, santoso.wijaya, socketpair, tshepang, petri.lehtinen, Arcege
2016-02-11 03:26:40martin.pantersetmessageid: <1455161200.37.0.956225076159.issue12463@psf.upfronthosting.co.za>
2016-02-11 03:26:40martin.panterlinkissue12463 messages
2016-02-11 03:26:39martin.pantercreate