First of all the daemon_threads property on socket
servers should be added as an optional arg to the
server constructor, so you can say:
     TCPServer(..., daemon_threads=True).serve_forever()

instead of

    temp = TCPServer(...)
    temp.daemon_threads=True
    temp.serve_forever

Secondly there should be a way to STOP the server, once
you've started serving forever!  A request handler
should be able to say

   self.server.stop_serving()

This would work by setting a flag in the server object.
 The serve_forever loop would use select with a timeout
(default 0.5 sec, also settable as an optional arg to
the server constructor) or alternatively set a timeout
on the socket object.  So it would block listening for
new connections, but every 0.5 sec it would check the
stop_serving flag and break out of the loop if the flag
was set.

This method was suggested by Skip Montanaro in a clpy
thread about how to stop SocketServer and it's useful
enough that I think it should be part of the standard
impl.  I can make a patch if it's not obvious how to do it.

This is getting in my way, so I'll take a look at it. I'm planning to
model the shutdown API after
http://java.sun.com/javase/6/docs/api/java/util/concurrent/ExecutorService.html.
The serve_forever->shutdown interval should probably also be available
through a context manager.

I had some code here to do the exact same thing with XML-RPC server. The
patch adds the feature to SocketServer, with a server.shutdown() method
to stop serve_forever(), and change the unittest to use and test the
feature.

I disagree on adding the daemon_threads arg as a keyword to TCPServer
since that's a feature of ThreadingMixIn

Polling isn't a great way to handle shutdown, since it wastes CPU time
and decreases responsiveness, but it's also easy and my attempt to avoid
it isn't getting anywhere, so I'm planning to fix up your patch a bit
and commit it. Thanks!

I've merged your patch with my conflicting change in the trunk and
re-attached it.

Two things:
1) This patch may interfere with the existing timeout in await_request.
We may be able to re-use that instead of having two select statements.

2) I believe it's important to provide a way to block until the server
isn't accepting any more requests and to block until all active requests
are finished running. If the active requests depend on other bits of the
system, blocking until they're done would help them terminate
gracefully. It would also be useful to give users a more proactive way
to kill active requests, perhaps by listing the handler objects
associated with them (or their PIDs for forking servers). It's
surprisingly complicated to avoid race conditions in these
implementations, especially without support from the Server object.

Also, Pedro's argument against a daemon_threads argument to TCPServer
convinces me. I think we can add it in ThreadingMixIn.__init__ once this
whole hierarchy is switched over to new-style classes. That's already
done in 3.0, but I don't know what it would affect in 2.6. If anyone
wants to keep pushing it, would you open a new bug?

It seems that .await_request() was only added a month ago to fix issue
742598, so it's no great hardship to refactor it again now. Timeouts
never worked for .serve_forever() because the try/except in
.handle_request() turned their exception into a plain return, which
didn't stop .server_forever() from looping. Timeouts also seem to be
unnecessary in a situation in which shutdown works. Shutdown can only be
called from a separate thread, and when you have more threads you can
also do periodic tasks in them.

So I've made that explicit: the .serve_forever/shutdown combination
doesn't handle timeouts. [This has nothing to do with the fact that it
takes three times as much code to handle them. Don't look at the excuse
behind the curtain. ;)]

This patch needs some more documentation and a NEWS entry before it gets
submitted, but I want to check that everyone would be happy with the
concept.

I'll submit the attached patch in a couple days unless I get comments.

Hearing no objections, I've submitted this as r61289.

So this has a race. See issue 2302 to discuss a fix.