apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: cvs commit: apr STATUS
Date Wed, 26 Dec 2001 06:02:24 GMT
On Tue, Dec 25, 2001 at 09:47:12PM -0500, Jeff Trawick wrote:
> Other than performance, why should the caller care?  The lock can't
> block.  Unbeknownst to the caller we or libc get locks on other
> callers.
> 
> Still curious,

Hmm.  Let me try and restate it.  It's a feeling that doing this
would be more than simply "creating" a lock - we're also "testing"
it.  I absolutely see why we need it, but it makes me uneasy to
do this automatically in all cases.  I wish that this were an
option that the caller could opt-in.

Consider the case of doing system-call tracing (via truss
or strace or ktrace).  You'll get possibly confused by having
the extraneous lock/unlock.  If you look at the APR calls on
the surface, you wouldn't know that there is an extra lock/unlock
done on this new lock at creation-time.

Other than the option/flag alternative, I'm not seeing another 
way to do this.  And, I believe that we should catch this at 
creation time, so...  -- justin


Mime
View raw message