Thank you for your fast response as well.

I overlooked that paragraph indeed.  It doesn't mention anything about avoiding a socket shutdown however.  Keeping a list of requests isn't very useful if all the sockets in the list are closed. ;-)

So I would indeed suggest an addition: I would change this paragraph:

These four classes process requests synchronously; each request must be completed before the next request can be started. This isn’t suitable if each request takes a long time to complete, because it requires a lot of computation, or because it returns a lot of data which the client is slow to process. The solution is to create a separate process or thread to handle each request; the ForkingMixIn and ThreadingMixIn mix-in classes can be used to support asynchronous behaviour.

into:

By default, these four classes process requests synchronously; each request must be completed before the next request can be started. This isn’t suitable if each request takes a long time to complete, because it requires a lot of computation, or because it returns a lot of data which the client is slow to process, or because the information that should be sent to the client isn't available yet when the request is made. One possible solution is to create a separate process or thread to handle each request; the ForkingMixIn and ThreadingMixIn mix-in classes can be used to support asynchronous behaviour. Another option is to store the socket for later use, and disable the shutting down of the socket by overriding process_request with an function that only calls finish_request, and not shutdown_request. In that case, the socket must be shut down by the program when it is done with it.

At the end of the last paragraph you refer to, it should also be mentioned that the program must do something to prevent the socket from being shut down.  In the description of process_request, it would probably also be useful to add that the default implementation (as opposed to *MixIn) calls shutdown_request() after finish_request().