apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: WriteLock ++ ;)
Date Sat, 28 Apr 2001 23:55:09 GMT
On Sat, Apr 28, 2001 at 07:29:02PM -0400, Christian Gross wrote:
> I just looked at the UNIX based RW lock stuff.  There is one
> difference between what I uploaded and what Justin uploaded.  He used
> one method call to acquire a reader or writer.  I used two.  Which one
> is right?
>
> I used two function calls because I thought it would keep things as
> simple and fast as possible.  I looked in the UNIX code and within the
> apr_lock_acquire_rw routine there is a switch to test which type of
> lock to acquire.  I would tend to say two method calls would be faster
> (OK it is splitting hairs ;) )

I think it's a matter of preference.  I interpreted it as you want to 
acquire a lock, but you need to choose which type of lock you want 
receive.  Again, no big deal.  At this point, I think the fewer functions 
added, the better.  And, in the grand scheme of things, a switch statement
isn't going to cost THAT much.  IMHO, the more readable the code is, 
the better.  If you want raw speed with the fewest lines of code, you 
sure won't be using APR.

> Another question that I have is follows.
>
> A user creates a regular lock and calls the RW lock routines or
> creates a RW lock and calls the regular lock routines.  What happens?
> In the Windows PATCH I decided to return an error saying this is not
> possible.  However because of that I had to modify the apr_errno.h
> file to include an extra error code.

In my implementation on POSIX platforms, it actually calls 
apr_lock_acquire_rw(lock, APR_READER) if you call apr_lock_acquire
on a APR_READWRITE lock.  You could make the case that they really 
want a writer lock.  Or, I think APR_ENOTIMPL suits as well.  Another
gray area.

> BTW I just caught an error in the Windows routines in that when the
> lock is cross process my reader writer will fail.  Need to fix that...

Cross process?  I'm ignoring the scope of the RW locks since POSIX 
RW locks *can't* be implemented cross-process.  fcntl() locks can be
cross-process.  Can Windows rw locks be cross-process (oh, does the
kernel somehow get involved)?  I thought about returning APR_ENOTIMPL
when they specified the scope, but I thought it would be better to 
just ignore it.  Hmm.

We should probably integrate our patches into one to make it easier
on others...

Two platforms down, two to go.  -- justin


Mime
View raw message