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
From: Stuart Donaldson <stuartd@al...> - 2002-12-17 18:13:58
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
> -----Original Message-----
> From: Geoffrey Talvola [mailto:gtalvola@...]
> 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: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
> > 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