[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
On Wed, Feb 7, 2018 at 2:01 AM, Chuck Silvers <chuq%chuq.com@localhost> wrote:
> On Tue, Feb 06, 2018 at 07:06:33PM +0900, Ryota Ozaki wrote:
>> 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.
Main Index |
Thread Index |