apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Gross <ChristianGr...@yahoo.de>
Subject Re: WriteLock ++ ;)
Date Sun, 29 Apr 2001 01:28:05 GMT
>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


View raw message