Given that some things work a little different between NT/Unix, can you put a quick test in and see if the catch KeyboardInterrupt is ever getting called, and let me know?
I can incorporate some cleanup into my subclassable ThreadedAppServer patch. Part of which will make it so experiments like Ian's NewThreadedAppServer could be done through subclassing, rather than re-implementation. That way the NT/Unix differences can be kept in as few places as possible. (I am aware that the NewThreadedAppServer also cleans up some stuff in ThreadedAppServer so it is a little more than just a new paradigm for the socket handling...) -Stuart- > -----Original Message----- > From: Geoffrey Talvola [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, December 17, 2002 9:31 AM > To: Stuart Donaldson; Webware-Devel (E-mail) > Subject: RE: [Webware-devel] ThreadedAppServer keybard interrupt and > termi nation > > > 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
