We should stop the cherrypy server cleanly

[GoogleCodeExporter]

Currently, we don't call cherrypy.server.stop() - we just allow the process
containing the server to stop without calling this.  This is because we
used to call cherrypy.server.stop, but found that it blocks indefinitely
sometimes, whereas simply terminating the process without calling it seems
to work fine.  This feels unclean though, and could have side effects we
haven't yet noticed, so we should investigate _why_ cherrpy.server.stop()
sometimes blocks indefinitely, and try and fix it.

Original issue reported on code.google.com by boulton.rj@gmail.com on 6 Dec 2007 at 12:09

[GoogleCodeExporter]

Why side effects might there be?

- The port isn't released, so other things can't use it (or we can't reuse it 
if we
restart).

I test shutting down and restarting quickly on windows and this doesn't seem to 
be a
problem.

I guess in any case things will time out although I don't know how long that 
normally
takes. 

(I suppose there's also the possibility that cherrypy is in fact cleaning up - 
e.g.
by catching SystemExit somewhere or registering something with atexit.)

Original comment by paul.x.r...@googlemail.com on 7 Dec 2007 at 8:57

[GoogleCodeExporter]

That's the main side effect I'm thinking off - it certainly is an issue in some
environments, though perhaps not in windows.

Also, though much more speculatively, we intend to use the flax core in many 
other
situations - in some situations it may be embedded in another application, and 
it
would then be important that it could be started and stopped as required, 
without
having to kill the application.

We can probably put this as a low priority issue, though.

Original comment by boulton.rj@gmail.com on 7 Dec 2007 at 9:52

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Original comment by charliej...@gmail.com on 27 Aug 2009 at 1:19

• Added labels: Module-FlaxBasic