From dev-return-884-daniel=haxx.se@subversion.apache.org Tue Jan 5 18:35:31 2010 Return-Path: Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by giant.haxx.se (8.14.3/8.14.3/Debian-9) with SMTP id o05HZUS3026919 for ; Tue, 5 Jan 2010 18:35:31 +0100 Received: (qmail 60994 invoked by uid 500); 5 Jan 2010 17:35:26 -0000 Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@subversion.apache.org Received: (qmail 60983 invoked by uid 99); 5 Jan 2010 17:35:26 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Jan 2010 17:35:26 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of hyrum_wright@mail.utexas.edu designates 146.6.25.7 as permitted sender) Received: from [146.6.25.7] (HELO ironclad.mail.utexas.edu) (146.6.25.7) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Jan 2010 17:35:14 +0000 DomainKey-Signature: s=main; d=mail.utexas.edu; c=nofws; q=dns; h=X-IronPort-MID:Received:Received:Received:Subject: Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To: X-Mailer; b=j8gTtbKC2WmQMo3GHXQY+7WjZFxXzxXpKw3XZMcFRsi8hMAg1VP0bxde 0q38dI3qFT+NRESL2i30gbsS+X3Hq0e3mnWAGdEU1OcXjfRkldpb4NZQX K5p8YO9JkmE77Sjd3oNYHqhPkvc14DApA7Q5frTQ0nRYmDpvCYfOsB7/G o=; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail.utexas.edu; i=hyrum_wright@mail.utexas.edu; q=dns/txt; s=main; t=1262712915; x=1294248915; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Hyrum=20K.=20Wright"=20|Subject:=20Re:=20wc-ng=20locks=20and=20pool=20clea nup|Date:=20Tue,=205=20Jan=202010=2011:30:59=20-0600 |Message-Id:=20|To:=20Philip=20Martin=20|Cc:=20dev@subversion.apache.org|Mime-Version:=201. 0=20(Apple=20Message=20framework=20v1077) |Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20<87ws0g458j.fsf@stat.home.lan> |References:=20<87ws0g458j.fsf@stat.home.lan>; bh=ppe8zUI2YbdqluqStzj+osIIxQDmr25OQjtjksZAriI=; b=PtGF7juKcN3yimPJOaEC4pyaF+TMDmvlbFzMGGr0bLHh64iBea6GdJWR 1H/uDahvm31voXmlMomQCUZ+EJxhxFvN0d45S7Wqr1uAXDbiXr6Aitthk ngYipM0TJbzxKrDhoP3mbQUqced03hcoc2hYkUrLPovKK05bJiH9bJAIG A=; X-IronPort-MID: 9067335 Received: from wb7-a.mail.utexas.edu ([128.83.126.146]) by ironclad.mail.utexas.edu with ESMTP; 05 Jan 2010 11:34:54 -0600 Received: (qmail 38487 invoked from network); 5 Jan 2010 17:34:53 -0000 Received: from 66-90-153-249.dyn.grandenetworks.net (HELO ?192.168.1.102?) (hyrum?wright@66.90.153.249) by wb7.mail.utexas.edu with (RC4-SHA encrypted) ESMTPSA; 5 Jan 2010 17:34:53 -0000 Subject: Re: wc-ng locks and pool cleanup Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: "Hyrum K. Wright" In-Reply-To: <87ws0g458j.fsf@stat.home.lan> Date: Tue, 5 Jan 2010 11:30:59 -0600 Cc: dev@subversion.apache.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <87ws0g458j.fsf@stat.home.lan> To: Philip Martin X-Mailer: Apple Mail (2.1077) X-Virus-Checked: Checked by ClamAV on apache.org On Dec 21, 2009, at 11:16 AM, Philip Martin wrote: > In 1.6 wc locks were associated with access batons and when an access > baton was opened a pool cleanup handler was installed to ensure that > the baton was closed. The pool cleanup handler would remove any lock > associated with the access baton provided there were no log files in > the directory. Code was typically: >=20 > svn_wc_adm_access_t *adm_access; >=20 > SVN_ERR(svn_wc_adm_open3(&adm_access, ... pool)); >=20 > SVN_ERR(svn_wc_foo(adm_access, ... pool)); >=20 > SVN_ERR(svn_wc_adm_close(adm_access)); >=20 > If svn_wc_foo completes without error then svn_wc_adm_close is called > which removes the locks unconditionally. If svn_wc_foo returns an > error then svn_wc_adm_close doesn't get called, and when the pool is > finally cleared the pool cleanup handler will leave or remove the lock > depending on whether cleanup is required. >=20 > The locks in wc-ng don't have the same behaviour, they only get > removed by an explict svn_wc__release_write_lock call. If the code > above is simply converted to wc-ng code then an error from svn_wc_foo > will leave the working copy locked; that's what happens when I try to > convert libsvn_client/copy.c. The client code can be modifed to work > around this in various ways but I don't think it's a good idea to > require the client code to do this. >=20 > I think svn_wc__acquire_write_lock should associate the lock with a > pool and install a pool cleanup handler that removes the lock if the > workqueue is empty. I don't think it makes sense to use the db > context state_pool since applications may want to reuse the context > for multiple operations; the pool lifetime is too long. I think it > should be a pool passed in to svn_wc__acquire_write_lock so that the > caller can control the lifetime of the lock. I like the idea but wonder what impact (if any) would the use of = inherited locks have this scheme. Relatedly, I'm having a spot of bother with a patch of my own and the = use of pools to cleanup locks. In trying to switch to inherited locks, = I've ran into a scenario where the sqlite db for a lock is being closed = before are done using it, causing problems when we later attempt to look = up information in that database. -Hyrum=