Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
Stuart Donaldson [mailto:stuartd@...] wrote:
> I am working on a patch to integrate much of the functionality of the
> ThreadedAppServer.run() function into a method on
> ThreadedAppServer so it
> can be more easily subclassed.
> In trying to not break any existing functionality, I have a couple of
> The run function currently catches KeyboardInterrupt
> exceptions. However
> signals for this are also caught and directed to the shutDown
> function. Is
> there a case where the KeyboardInterrupt exceptions would get thrown?
Not sure. This might be paranoia or leftovers from an earlier version of
the code that didn't use signals.
> Would it make more sense if, after returning from mainloop()
> we checked to
> see if we were still running, and then called shufDown() if needed?
Sounds plausible to me.
> Also, the NT code never seems to call shutDown(), it just sets
> server.running=0. Is this a problem on NT? I don't have
> much NT/Python
> combined experience so I don't know why it might not want to
> call shutDown()
> and cleanup the queues.
But the signal code does cause shutDown() to be called on Windows, so it's
not necessary to call it after returning from mainloop because it's the call
to shutDown() that _caused_ mainloop to exit.
You do have a point that if the mainloop exits for some other reason than
Ctrl-C being called, then it looks like shutDown() won't be called. This is
where your proposed test to see if we're still running might help. In
practice, I can definitely vouch that the existing code for Windows seems to
This code is all kind of messy. If you can figure out how to clean it up
without breaking anything, more power to you :-) It's difficult to do a
good job because things work a little differently on Windows vs. Unix.