From dev-return-25271-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Thu Apr 18 09:58:54 2013 Return-Path: X-Original-To: apmail-apr-dev-archive@www.apache.org Delivered-To: apmail-apr-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D8CC1103B0 for ; Thu, 18 Apr 2013 09:58:54 +0000 (UTC) Received: (qmail 86786 invoked by uid 500); 18 Apr 2013 09:58:53 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 83387 invoked by uid 500); 18 Apr 2013 09:58:48 -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 83351 invoked by uid 99); 18 Apr 2013 09:58:46 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 18 Apr 2013 09:58:46 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: error (athena.apache.org: encountered temporary error during SPF processing of domain of codematters@ntlworld.com) Received: from [74.125.82.176] (HELO mail-we0-f176.google.com) (74.125.82.176) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 18 Apr 2013 09:58:41 +0000 Received: by mail-we0-f176.google.com with SMTP id s43so2029838wey.21 for ; Thu, 18 Apr 2013 02:58:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:x-proxyuser-ip:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version:content-type :content-transfer-encoding:x-gm-message-state; bh=xIERoKNjYnDVUK6q127yg5vK0Hkr+1nvRQMuvlUA8cs=; b=agmyHFexwFd5iEHHQFfu+9eWG5bM5hYzPdMv138TPFOt+vwTT/mlnBh+7zInvv19hW vy8F6K7ddL0Uj45LFnLSbm7MhM7SxUcUO51Oxj2QuJEh8oN3nXu0e8gQgER9RgecoJXW RAS5yrR682bV1X9lW0/D+QmrYh19vbiAfc0f8B2Sx6P9TUBCY2iLdI2a9/osOPCdA9ID 01XuieVxR4AYTb9vs0tPi/uEUBUVVd9VNHK1Ocz/bbyUcBaivAEFtu/DyrjQXBepkVdO dcxEWQ5AOAalldtBvzv1cKeRMMX9IugPVU927tfGvjOcZuT21HA8FtGt1fLB+6qIDQuM L52g== X-Received: by 10.180.73.173 with SMTP id m13mr16732878wiv.27.1366279080252; Thu, 18 Apr 2013 02:58:00 -0700 (PDT) Received: from (know-mailgateway-4.server.virginmedia.net. [62.254.26.109]) by mx.google.com with ESMTPS id bj9sm30395685wib.4.2013.04.18.02.57.58 (version=TLSv1.1 cipher=RC4-SHA bits=128/128); Thu, 18 Apr 2013 02:57:59 -0700 (PDT) Sender: MARTIN PHILIP Received: from source ([86.17.224.110]) by smtp.virginmedia.com with SMTP; Thu, 18 Apr 2013 09:57:59 +0000 (GMT) X-ProxyUser-IP: 86.17.224.110 Received: by cpc2-farn6-0-0-cust109.6-2.cable.virginmedia.com (Postfix, from userid 1000) id 9B2E280969; Thu, 18 Apr 2013 10:57:57 +0100 (BST) From: Philip Martin To: "William A. Rowe Jr." Cc: dev@apr.apache.org, i.galic@brainsware.org Subject: Re: undefined reference to `apr_pool_mutex_set' References: <553787790.462730.1366211441631.JavaMail.root@brainsware.org> <792240597.462741.1366211671567.JavaMail.root@brainsware.org> <20130417212743.32215a33@hub> Date: Thu, 18 Apr 2013 10:57:57 +0100 In-Reply-To: <20130417212743.32215a33@hub> (William A. Rowe, Jr.'s message of "Wed, 17 Apr 2013 21:27:43 -0500") Message-ID: <878v4gjh3u.fsf@ntlworld.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmYzVsnjbq2U8osRnqRC9zjAPuYPeyPUL0pHPPYiv5nChdLATNSFhL9rus8H4zAHVsX0Fo7 X-Virus-Checked: Checked by ClamAV on apache.org "William A. Rowe Jr." writes: > On Wed, 17 Apr 2013 15:14:31 +0000 (UTC) > Igor Gali=C4=87 wrote: >>=20 >> caused by this projects creative use of APR: >> https://code.google.com/p/unimrcp/issues/detail?id=3D29 >>=20 >> Is there anything I can do other than compile a sepcial version of >> APR for this project's requirements? > > That's what happens when projects don't push hacks upstream :( > Sorry we can't provide too much guidance. If there is a submitted > patch under the AL lying around somewhere, please flag it to the=20 > dev@ list for consideration. The patch adds a mutex to apr_pool_t and locks the mutex in calls to apr_palloc, apr_pool_clear and apr_pool_destroy. That may make those individual calls threadsafe but it doesn't really make pool use as a whole threadsafe. If one thread clears a pool every other thread using the pool is left with dangling references. It looks like a lot of locking for no real gain. --=20 Philip