Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Thu, 21 Jul 2005 15:20:42 +0100 (BST)
From: Nick Kew <nick@webthing.com>
To: Henry Jen <henryjen@ztune.net>
Cc: <dev@apr.apache.org>
Subject: Re: Recursive mutex
In-Reply-To: <42DEF9DF.4010902@ztune.net>
Message-ID: <Pine.LNX.4.33.0507211514130.540-100000@midgard.webthing.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


On Wed, 20 Jul 2005, Henry Jen wrote:

> I need to have recursive(NESTED) mutex support in our project.
>
> Currently apr is relying on pthread lib to provide
> pthread_mutexattr_settype to provide recursive support, unfortunately,
> that does not seem to be in POSIX standard and is not available on the
> requested linux platform(see
> http://www.lynuxworks.com/products/posix/function-calls.php3).
>
> I plan to implement that in apr by extend current apr_thread_mutex_t to
> include a pthread_t and an integer for count, and modify the lock/unlock
> accordingly. So here are couple questions:
>
> 1. Is this a reasonable solution or I overlook something? Or maybe
> someone had done similar?

Looks reasonable to me at first glance.  Bear in mind that anything
APR exports should be cross-platform, so you'll want to implement it
in the platform-independent layer.  Unless I'm misunderstanding the
scope of what you propose.

> 2. How fast can this modification can be rolled into a formal apr
> release? It is going to be API compatible but not ABI(as the structure
> changed, only in the case of underlying pthread lib does not support
> recursive mutex, so should be OK)

That's likely to be a while: it'll need to get reviewed, agreed on,
and then used in a test version for a while, then await sufficient
general agreement for a release incorporating it.

-- 
Nick Kew