> I wonder if all open file objects are kept open, though? That might be > a problem... I mean, not everything has to be perfect with auto-reload, > since it's still only meant for development purposes.
I checked on my system by looking in /proc/<PID>/fd for the appserver. I saw that I got a few extra open files after each restart, too (I think it was the database connections). MySQL didn't seem to mind, but I'd like to fix this if possible. I'm sure it would become a problem after a few hours of piled-up connections. > What we really want is for the Python interpreter to do a clean exit, > calling all finalizers, and then restart. I don't know if you can do > that with os.exec. Maybe we should ask comp.lang.python -- I'm sure we > could get a definitive answer from someone. I found this thread while googling, which shed a bit of light on the subject. http://mail.python.org/pipermail/python-list/2001-January/025343.html The python interpreter doesn't keep track of file descriptors; only the OS does. There's no portable way of getting a list of open files, which means that the only way to close all open files is to try to close every possible file descriptor, ignoring errors. Of course we want to leave 0,1, and 2 open (stdin,stdout,stderr); these _should_ be inherited by the new appserver. Unfortunately, when I stuck in code to do this (before the exec), the appserver process started spinning, and I had to kill -9 it. I've been trying to track down what's going wrong, and so far I've concluded that there are some pipes being opened that don't want to get closed (maybe it causes deadlock if you close them in the wrong order?). So far, I haven't been able to determine where they are being opened. Here's a typical listing of the appserver's open files: 0 -> /dev/null 1 -> /home/jdhildeb/projects/mobile/devapp/appserver.log 10 -> socket:[126562] 11 -> socket:[126564] 12 -> /usr/lib/python2.2/Cookie.py 2 -> /home/jdhildeb/projects/mobile/devapp/appserver.log 3 -> pipe:[9811] 4 -> /tmp/foo 5 -> /tmp/foo2 6 -> pipe:[126557] 7 -> pipe:[126557] 8 -> /tmp/foo5 9 -> /tmp/foo3 All of the "foo" entries are from my testing trying to find where the pipes are being opened, so you can ignore them. Numbers 6 and 7 cause the problems (i.e. you can close off all other descriptors without problems.). I'm going to pursue this further, since closing all file descriptors before the exec would be a fairly clean way of handling this. cheers, Jason -- Jason D. Hildebrand [EMAIL PROTECTED] ------------------------------------------------------- This SF.net email is sponsored by: ApacheCon, November 18-21 in Las Vegas (supported by COMDEX), the only Apache event to be fully supported by the ASF. http://www.apachecon.com _______________________________________________ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
