From dev-return-21196-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Tue Nov 25 18:51:01 2008 Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 29980 invoked from network); 25 Nov 2008 18:51:01 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 25 Nov 2008 18:51:01 -0000 Received: (qmail 21231 invoked by uid 500); 25 Nov 2008 18:51:05 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 21176 invoked by uid 500); 25 Nov 2008 18:51:05 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 21150 invoked by uid 99); 25 Nov 2008 18:51:05 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 25 Nov 2008 10:51:05 -0800 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [64.202.165.183] (HELO smtpauth03.prod.mesa1.secureserver.net) (64.202.165.183) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 25 Nov 2008 18:49:34 +0000 Received: (qmail 18315 invoked from network); 25 Nov 2008 18:50:10 -0000 Received: from unknown (76.252.112.72) by smtpauth03.prod.mesa1.secureserver.net (64.202.165.183) with ESMTP; 25 Nov 2008 18:50:09 -0000 Message-ID: <492C48E0.3090802@rowe-clan.net> Date: Tue, 25 Nov 2008 12:50:08 -0600 From: "William A. Rowe, Jr." User-Agent: Thunderbird 2.0.0.18 (X11/20081119) MIME-Version: 1.0 To: dev@apr.apache.org Subject: Re: svn commit: r719505 - in /apr/apr-util/branches/1.3.x: Makefile.in build.conf build/dbm.m4 build/dso.m4 dbm/apr_dbm.c dbm/apr_dbm_berkeleydb.c dbm/apr_dbm_gdbm.c dbm/apr_dbm_ndbm.c include/private/apr_dbm_private.h References: <20081121063258.F1E50238889B@eris.apache.org> <20081125130921.GA8955@redhat.com> In-Reply-To: <20081125130921.GA8955@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Joe Orton wrote: > On Fri, Nov 21, 2008 at 06:32:58AM -0000, William Rowe wrote: >> Author: wrowe >> Date: Thu Nov 20 22:32:58 2008 >> New Revision: 719505 >> >> URL: http://svn.apache.org/viewvc?rev=719505&view=rev >> Log: >> Introduce DBM DSO linkage. >> >> Backports: 719504 > ... >> Modified: apr/apr-util/branches/1.3.x/dbm/apr_dbm.c >> URL: http://svn.apache.org/viewvc/apr/apr-util/branches/1.3.x/dbm/apr_dbm.c?rev=719505&r1=719504&r2=719505&view=diff >> ============================================================================== >> --- apr/apr-util/branches/1.3.x/dbm/apr_dbm.c (original) >> +++ apr/apr-util/branches/1.3.x/dbm/apr_dbm.c Thu Nov 20 22:32:58 2008 > ... >> +static apr_status_t dbm_open_type(apr_dbm_type_t const* * vtable, >> + const char *type, >> + apr_pool_t *pool) >> +{ > ... >> + >> + if (!drivers) >> + { >> + apr_pool_t *ppool = pool; >> + apr_pool_t *parent; >> + >> + /* Top level pool scope, need process-scope lifetime */ >> + for (parent = pool; parent; parent = apr_pool_parent_get(ppool)) >> + ppool = parent; >> + >> + /* deprecate in 2.0 - permit implicit initialization */ >> + apu_dso_init(ppool); >> + >> + drivers = apr_hash_make(ppool); >> + apr_hash_set(drivers, "sdbm", APR_HASH_KEY_STRING, &apr_dbm_type_sdbm); > > This surely isn't thread-safe? Two threads could enter apr_dbm_open*() > with drivers == NULL and then call apu_dso_init() on the same global > pool, which would break. That is correct. Let's explore a little deeper, though? http://svn.apache.org/repos/asf/apr/apr-util/trunk/misc/apu_dso.c dsos' is a singleton, and apu_dso_init() may be (safely) called multiple times to ensure the dso services are available. If nobody has performed any database, sql, ldap or other access prior to thread creation and race-for-first, then you are right. It won't break, but it certainly can cause a double-load artifact due to the race. The point to the global shared pool is that the process-loaded provider is global to all players. The contract needs firming up, but "break" isn't quite the right word. Redundant, certainly, and in 2.0 we have a chance to make all these mechanics simpler. But this is no different than the current (and former) loadable dbd provider issue.