> This page lists all known servers (known to this profile) and in the > (remote/downloaded) results.xml we now have strings that contain formatted > start/end dates/times in local and UTC. This table ought show us our > "windows of opportunity". [It shows me that DOTNOT and Hermes need taking a > look at, and that I bust Try regularly w/ documentation testing.]
Both DotNot and Hermes were stuck due to having a gumpy.lock file in existence. I introduced the lock because if two Gumpys run at the same time they fight terribly, and it explodes their memory usage to major bloat. That said, ever since I've introduced the lock, we've had nothing but false positives with it, each requiring manual cleanup. :( The lock file is created by gumpy.py, and contains the PID of the process that created it. In a 'finally' clause the file is removed. It remains around (however) if the gumpy is killed, and there seems no Python (heck, any language) way to ensure it is removed. As such, I'd like logic for knowing when to ignore it and proceed. The obvious is to see if the process is running, but I do not believe this is possible (portably) in Python. I'll enter a JIRA entry to look into a real locking mechanism, one where the OS cleans up upon process termination. [Probably something to do with lockf().] regards Adam --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
