Waitress leaves background threads running when socket creation fails

[mgedmin]

This is a very minor, cosmetic issue.

waitress.server. creates a ThreadedTaskDispatcher() with several threads before it creates and binds the listening socket. If an exception happens during the latter, this task_dispatcher is garbage-collected with no way left of calling .shutdown() on it, which leaves the threads running. The threads are daemon threads, and so they're mostly harmless.

What makes me slightly unhappy is that zope.testrunner complains about unit tests creating new threads that are not properly stopped before the next test runs, and this happens in my unit test where I'm testing my socket.error handling.

Would there be any problems with reordering the code to create the task dispatcher after the socket?

Also, BaseWSGIServer.close() doesn't call self.task_dispatcher.shutdown() while MultiSocketServer.close() does. Is that intentional? It feels a bit weird that I have to do it myself when I call create_server() with one listening address, but not if I pass multiple.

I'm using waitress 3.0.2, for the upcoming version of zodbbrowser.

[jvanasco]

I'm making a PR to log the bind failures (see #471)

A few things that popped out at me:

• task_dispatcher is not properly documented or typed
• i assume the path you're dealing with is in create_server. quickly looking at that, I see a few places where the application could similarly fail (random objects garbage collected and hidden away).

I wonder if a more robust solution would be wrapping much of this logic in a try block, either inline or through a private function, so the failed objects could be better tracked and handled.