Mercurial > hg
view hgweb.cgi @ 23032:f484be02bd35
lock: while releasing, unlink lockfile even if the release function throws
Consider a hypothetical bug in the release function that causes it to raise an
exception. Also consider the bisect command, which saves its state in a finally
clause. Saving the state requires acquiring the wlock.
If we don't unlink the lockfile when the exception is thrown, we'll try to
acquire the wlock again. We're going to try and acquire a lock again while our
old lockfile is on disk. The PID on disk is our own, and of course we're still
running, so we won't take over the lock. Hence we'll be stuck waiting for a
lock that we left behind ourselves.
To avoid this, always unlink the lockfile. This preserves the invariant that
self.held > 0 is equivalent to the lockfile existing on disk.
author | Siddharth Agarwal <sid0@fb.com> |
---|---|
date | Thu, 16 Oct 2014 19:15:51 -0700 |
parents | 85cba926cb59 |
children | 4b0fc75f9403 |
line wrap: on
line source
#!/usr/bin/env python # # An example hgweb CGI script, edit as necessary # See also http://mercurial.selenic.com/wiki/PublishingRepositories # Path to repo or hgweb config to serve (see 'hg help hgweb') config = "/path/to/repo/or/config" # Uncomment and adjust if Mercurial is not installed system-wide # (consult "installed modules" path from 'hg debuginstall'): #import sys; sys.path.insert(0, "/path/to/python/lib") # Uncomment to send python tracebacks to the browser if an error occurs: #import cgitb; cgitb.enable() from mercurial import demandimport; demandimport.enable() from mercurial.hgweb import hgweb, wsgicgi application = hgweb(config) wsgicgi.launch(application)