Stuart Donaldson [mailto:[EMAIL PROTECTED]] 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 > questions: > > 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 work properly. 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. - Geoff ------------------------------------------------------- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ _______________________________________________ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
