On Wed, Feb 7, 2018 at 2:01 AM, Chuck Silvers <c...@chuq.com> wrote: > On Tue, Feb 06, 2018 at 07:06:33PM +0900, Ryota Ozaki wrote: >> Hi, >> >> Is there any reason that rw_lock_held checks if it's held >> by *someone*, not by curlwp? It's confusable and most (or all?) >> users of the API seem to expect the latter (held by curlwp). >> >> Well, rwlock.9 says that rw_*_held behave so, but that's perhaps >> just out-of-date because rw_read_held and rw_write_held check >> if it's held by curlwp. >> >> So I think we should do either: >> (1) fix rw_lock_held, or >> - probably it would be rw_read_held() || rw_write_held() >> (2) fix users of rw_lock_held. >> - it also would replace rw_lock_held with >> rw_read_held() || rw_write_held() >> >> I prefer (1) because I think there is no user of the current >> behavior that is difficult to use for users (it may be useful >> as an internal utility function though). >> >> Any thoughts? > > > your option (1) sounds fine to me. > a better wording for the manpage could be: > > Test the lock's condition and return non-zero if the lock is > potentially held by the current LWP and matches the specified > condition. Otherwise, return zero. > > thus if we see that lock is held (in write mode) by some other LWP then > we know that is not even potentially held by the current LWP.
I think we don't need "potentially" anymore. And "matches the specified condition" is unclear to me (I know it's the original wording). So I prefer the following one though it's a bit redundant: rw_write_held() returns non-zero if the lock is held by the current LWP for write. rw_read_held() returns non-zero if the lock is held by the current LWP for read. rw_lock_held() returns non-zero if the lock is held by the current LWP for write or read. Otherwise, these functions return zero. ozaki-r