refactor(bdev/lock): add range lock trait #51
Conversation
tiagolobocastro
requested review from
dsavitskiy,
hrudaya21,
abhilashshetty04 and
dsharma-dc
tiagolobocastro
force-pushed
the
lock-range
branch
from
2a64752 to
dfbc4e0
Compare
|
|
||
| /// Allows gaining exclusive access over a block range. | ||
| /// # Warning | ||
| /// Due to the lack of async drop the range lock must be |
There was a problem hiding this comment.
I wonder if we can still release in the drop method, just not wait for it - and then the caller may decide to either wait or just allow the drop to do it if it doesn't care about waiting for unlock to complete, wdyt @dsavitskiy ?
There was a problem hiding this comment.
As I understand this drop part - since we have nothing custom to do in Drop, and the allocated heap memory will be anyway freed by default drop, it seems ok to wait for unlock to complete.
tiagolobocastro
force-pushed
the
lock-range
branch
from
dfbc4e0 to
c3883e7
Compare
|
What's the rationale for this change? Perhaps you can update in PR description. |
done |
|
|
||
| /// Allows gaining exclusive access over a block range. | ||
| /// # Warning | ||
| /// Due to the lack of async drop the range lock must be |
There was a problem hiding this comment.
As I understand this drop part - since we have nothing custom to do in Drop, and the allocated heap memory will be anyway freed by default drop, it seems ok to wait for unlock to complete.
tiagolobocastro
force-pushed
the
lock-range
branch
from
c3883e7 to
d0e9602
Compare
tiagolobocastro
force-pushed
the
develop
branch
from
ce34760 to
3214ded
Compare
Signed-off-by: Tiago Castro <[email protected]>
tiagolobocastro
force-pushed
the
lock-range
branch
from
d0e9602 to
e65eaa3
Compare
|
I ended up not requiring this, so closing it for now. |
Makes the range locking an interface which can be implemented by different types.