The Python docs recommends using `.serve_forever()` for running a multiprocessing manager.
The problem is, that unlike any equivalent `.serve_forever()`, this specific one calls `sys.exit()` and exits the program. This in turn may cause issues if that's not the only use of the Python program, as seen here:
https://stackoverflow.com/questions/70284538/overriding-a-built-in-class-method-that-another-class-i-want-to-inherit-from-rel
3 possible solutions:
1. Remove `sys.exit()`: This will cause `shutdown()` to not actually shut down. The function counts on the `.accepter()` daemon thread to close, but if other code is preventing that process from closing, it will continue uninterrupted.
2. Remove `sys.exit()` and check the `stop_event` inside the `.accepter()` daemon thread: This will only partially shut down. The socket will still listen and will only close when the listener receives a command. An option to solve it would be to dispatch a shutdown command, or close the Listener forcibly using `.close()`. All in all, I believe this is the best option.
3. Discourage the use of `serve_forever()`: Right now the way it looks, server is not implemented too well. Its `serve_forever()` function is endorsed by the docs, but the class itself is completely undocumented, with no documentation on any of its functions, and it shuts down the process calling the function when it finishes which is dubious at best. There are plenty more issues scattered around the bug tracker, one of them about its finalization due to the use of daemon threads. Everything can be implemented using start() together with an event. The only reason I don't like this option, is because `serve_forever()` does seem convenient and can be fixed per option 2.
I'll start implementing option 2 in the background, together with adding documentation, but I would enjoy gathering more feedback.
|
➜
