Panda3d network server running in a thread

Hi everyone,
I am attempting to create a server side application for panda3d clients to connect to.
With this in mind, I figured I could run the server side panda3d app in a thread, but this has been problematic.
For those of us developing servers, it would really be nice if panda3d could support being run not on the main thread. I can get it to work by commenting out the signal.signal calls in Task.py, but this is not a good solution.
So it seems like Task.py needs to be changed to explicitly support a multi-threaded environment.
I would like to be able to capture the ctrl+c or sigint events from my mainthread, and use that to do cleanup of other modules/subsystems as well as get panda to do graceful cleanup.
Commenting out the signal.signal calls practically ensures the ctrl+c will come at a bad time, say in the middle of Task.step.
As an example of why I want to do this in the first place, suppose you wanted to create some kind of admin or control interface for your game server.
One way would be to run an http server and allow web based control of the server.
In this case, the main thread would start one background thread for the panda portion of the app, and a second thread for the http requests.
Then when the operator hits ctrl+c I can safely shutdown the web server as well as panda.
Is this possible?

Thanks

For anyone who comes along after me with the same problem:

I decided to quit fighting with panda and just let it have the main thread. This left me with cherrypy running in another thread. I tried to register an atexit handler that would cleanup connections and then ask cherrypy to shutdown nicely. But this didn’t work, because when I hit ctrl+c, panda catches the keyboard interrupt, and calls sys.exit, and I can only assume, does all of its internal cleanup. As part of that, it tries to join all threads, including my cherrypy thread (which is still active). This leads to a hang. So rather than explicitly cleanup either panda or cherrypy, I set the cherrypy thread to daemon mode, and then it “auto” cleans up after the ctrl+c event, though it does throw a runtime warning.