> I don't see a need for "nice" on brutus. The purpose of that machine is > to run Gump. If performance becomes a problem, we can ask for help to > get the machine to take advantage of it's second CPU and additional memory.
Ok, cool. BTW: Remember those nice fast runs? They seem a lot slower these days. I've not had time to investigate why, but I am curious why the dropped off. That said, things seem slow as mollasses today (whereever I touch) and I don't seem to be able to figure out why. > When hermes goes into production, we may lose it for Gump purposes. > Meanwhile, nice there might be a good idea. Of the two, Hermes is proving more tricky to deal with, for us and for projects. Not sure if that makes it a shame if it goes away, or a relief ;-). > Having gump first sniff to see if it is current running and quickly exit > if so might be a good idea. Perhaps using some code like this: > > http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/65203 You mean something like this? ;-) http://cvs.apache.org/viewcvs.cgi/gump/gumpy.py?view=markup def establishLock(lockFile): failed=0 info='' if 'posix'==os.name: import fcntl try: lock=open(lockFile,'a+') fcntl.flock(lock.fileno(), fcntl.LOCK_EX | fcntl.LOCK_NB) except: failed=1 info=', and is locked.' else: if os.path.exists(lockFile): failed=1 # Write this PID into a lock file lock=open(lockFile,'w') if failed: print """The lock file [%s] exists%s. Either Gump is still running, or it terminated very abnormally. Please resolve this (waiting or removing the lock file) before retrying. """ % (lockFile, info) sys.exit(1) # Leave a mark... lock.write(`os.getpid()`) lock.flush() return lock regards Adam --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
