On Fri, Apr 25, 2008 at 06:08:17AM -0400, Richard Lowe wrote: > > If the user issues ^C while runchecks() is running then I have to find the > > remote-side hg process and kill it to release the repository lock. It's not > > clear to me that adding signal handling for SIGHUP to runchecks() would > > resolve this issue. Something to try, anyway. Or maybe I can do it in > > hg-ssh? > > That I don't know about, repo.lock/wlock are released by __del__ > methods which run when GC gets to them. What we found with an older > issue that used to be in cdm (and that Matt warned us about), is that > python's GC won't deal with circular references, so you can get > yourself into a state where the lock objects will never actually be > GC'd. I have no idea if that's what's happening to you (I'm not > certain if by "repository lock" you mean repo.lock/repo.wlock, or a > lock of your own).
I don't know what the lock name is; my gate code doesn't contain any lock of my own creation. I just had some message from my hg client that said something about a lock. The next time I see it I'll have to pay more attention to what is happening. Dean
