apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: [PATCH] global mutex for anylock
Date Sat, 04 Feb 2006 18:43:31 GMT
Something we need to make a decision on that was discussed on IRC...

the new patch introduces a new enumerated possible lock type.  Now in theory,
if you compile into a apr-util derived module built against 1.2 and prior,
after this patch it can create an 'unknown lock type'.  Any operation on
this apr_anylock by the older module results in APR_EINVAL.

Do our versioning rules permit this fail (with no corruption) case to let
us commit this to 1.3.0?  Or will this have to be an APR 2.0.0 change?

I'm partial to including this in 1.3.0, and see no harm in unknown lock.
But if someone delegated the cleanup of the apr_anylock to this hypothetical
derived module built against 1.2, we would see a leak.  In theroy, the same
code which allocates and object should be responsible for destroying it, so
I don't see this as a likely scenario.

Bill

Dirk Groeneveld wrote:
> Hi!
> 
> This patch adds global mutexes to anylock. I talked to wrowe last  night 
> on #apr and he gave me (hopefully) everything I needed to know  to write 
> it. I am marvinalone (on freenode).
> 
> It compiles fine where I am (on Mac OS X with gcc 4.0.1), but I  didn't 
> get a chance to test it somewhere without APR_HAS_THREADS or  with 
> APR_PROC_MUTEX_IS_GLOBAL (which would make a difference).
> 
> Cheers,
> Dirk
> 


Mime
View raw message