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
