At 12:44 AM 2/8/99 -0800, Quinn Dunkan wrote:
One more general purpose way of handling shutting down is to include a published method which shuts down python, for example:
def shutdown(): "should require authorization to call this" raise SystemExit
Yeah, but fcgi runs a seperate python for each cgi, so I'd need to somehow communicate with that python. My ideal solution would be to have publish_module() reload its module every time (which is no time loss if the module hasn't changed). How can I tell publish_module() to do this? Ick, this doesn't deal with submodules properly, what I want is to have publish_module() re-import everything every time. Maybe if I take them
out of
sys.modules...
I'm also having trouble with ZP exceptions, threads, sockets, and a few other things.
Phillip was mentioning his fcgi efforts, so perhaps I needn't worry. My current approach is to use the fcgiapp module and an fcgi-module-publisher that's similar to cgi-module-publisher with fcgi.Accept() and fcgi.Finish() around it. Phillip, as soon you've gotten your fcgi working I'd love to see what you come up with.
If you check back in the list archives, looking for "Launcher.py" you should be able to find the first fcgi support code I did. It supports specifying MAX_REQUESTS, IDLE_TIMEOUT, and MAX_LIFETIME settings so the server will die after a set period. During development, it can be useful to set these all low, so that in the amount of time it takes you to make a code change, the server will have died off due to inactivity. :) And if it didn't die due to idleness, you can always hit reload a few times and max out MAX_REQUESTS. :) In practice, I hardly ever do this, as I use ZPublisher as the front-end to a Zope-like application server that runs off the filesystem instead of a ZBase. The app server notices when timestamps change and automatically reloads the files, so I don't have to kill off the server to see changes unless I'm changing the engine itself. My newer FastCGI code is more a matter of changing to use Robin Dunn's "fcgi" module in place of DC's "fcgiapp" so that it can be run multithreaded, and creating a class framework for standalone publishers that takes care of most of the messy plumbing overhead. I'm factoring the code into (proposed) ZPublisher.Config and ZPublisher.Plumbing. I hope to have some working code to present today. ZPublisher.Config is working quite spiffily, and most of the base Plumbing class is ready to go. I'm going to make test CGI(Plumbing) and FastCGI(Plumbing) classes next.
You get the idea. I can just wrap my published objects in a try except but that gets tedious after a while. Zope also still uses string exceptions. Unless there is significant need for python 1.4 compatibility, it shouldn't be too hard to come up with some sort of simple hierarchy, is that in the works?
You should be aware that there is a significant performance penalty for using class exceptions, if your code throws them a lot. This is particularly noticeable with Acquisition, which does deep searches a fair bit faster with the -X flag on.