>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. > Again I agree with you and to me it does not matter which way. To be honest either way is ok with me. The question is how do we decide? How about we use the APR random function to flip a coin? ;)
Anyone on the Apache APR team wish to make a comment? Justin, if you are please excuse my ignorance. >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. > Regarding the comment that the lock request is really a writer lock, yes that case could be made. Actually that is what I was thinking in my mind. I decided against it because when the lock is created and it is a simple lock certain structures are not filled in. But yes I agree another gray area. >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. > On the Windows platform the locks can be cross-process. Hence right now there is the problem that the RW locks will break between processes. If they cannot be supported on the POSIX platform then return APR_ENOTIMPL probably would be a good thing. >We should probably integrate our patches into one to make it easier >on others... > Ah, yes I agree with you. So how about we do the following. One function, but return an error when using the wrong lock acquire function is called? All OK? Any comments? >Two platforms down, two to go. -- justin Yupe.... Christian
