Just a quick thought -- it might be easier to put this into the AppServer script, and say if Launch.py exits with a certain error code it will restart the AppServer (instead of just exiting). Then the process fully exits, and all files will be cleaned up by the OS. I'm pretty sure AppServer.bat could do this too (somehow... despite the lameness of batch programming).
On Sat, 2002-10-26 at 17:10, Jason Hildebrand wrote: > > 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
