Refuse to destory rwlock if it is held by other thread. It is a
robustness check and the user should not relies on EBUSY to check
whether it is held by other. Even through POSIX doesn't require it, I
think it still worth to do so.
Details
Details
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 78480 Build 75363: arc lint + arc unit
Event Timeline
| lib/libthr/thread/thr_rwlock.c | ||
|---|---|---|
| 135 | What if the current thread owns the lock? Your commit message says 'other threads'. In fact I am not sure what would be an impact of such change on apps. | |
| lib/libthr/thread/thr_rwlock.c | ||
|---|---|---|
| 135 | Oh It should be "any thread". When I was writting comment, I am thinking about that if a lock is held by the thread itself. They should know that we cannnot destroy the lock. I think it prevents us from deleting a rwlock while anybody (or thread) is pending. it might be due to a thread is not destoryed properly. | |
Comment Actions
So what are the benefits of the change?
It does not guarantee that EBUSY is returned, so consumers cannot rely on it (lets ignore portability aspects).
If code is not accurate to not destroy locked rwlock, then perhaps it is also not accurate to check the result of _destroy(). And then the result is a memory leak instead of potential fault on unlock.
I do not object, but also I do not see much benefits.
Comment Actions
It is (a little bit) useful as it eliminates some use-after-free bug. Also, it matches our mutex code. But I also acknowledge that there are few people check return value on its own.
An useful example is that I fix one use after free bug on LLVM upstream (not rwlock but on mutex) due to freeing mutex while holding. I can reproduce stably because we have such check and libcxx did assertion over the return value of free mutex call. See: https://github.com/llvm/llvm-project/pull/209019.