The SDK has a concept called a state store lock. This is a Mutex protecting... Well nothing:
|
/// Get a lock to the state store, with an exclusive access. |
|
/// |
|
/// It doesn't give an access to the state store itself. It's rather a lock |
|
/// to synchronise all accesses to the state store. |
|
pub fn state_store_lock(&self) -> &Mutex<()> { |
|
self.state_store.lock() |
|
} |
Though the rule is for this lock to be acquired whenever we'd like to write to the state store. It mainly protects the RoomInfo from being mutated by two places at the same time.
This used to be fine, as we had very few places where we would modify the RoomInfo, i.e. the sync used to be the only such place.
Now the RoomInfo operates in a copy-on-write manner. This allows us to process the sync in peace without having to block users from accessing the RoomInfo. We do this with the clone_info() method:
|
/// Clone the inner `RoomInfo`. |
|
pub fn clone_info(&self) -> RoomInfo { |
|
self.info.get() |
|
} |
This setup makes it quite easy to mess things up, people need to remember that the lock needs to be taken, furthermore it needs to be taken before any clone_info() calls.
Proposed solution
Since we don't want to get rid of the copy-on-write properties, I propose that the state store lock, gives out a token of some sort.
This token must be used in the clone_info() method. This prevents users to clone the info without taking the state store lock.
The token can be a simple unit struct which the state store lock now protects.
The SDK has a concept called a state store lock. This is a
Mutexprotecting... Well nothing:matrix-rust-sdk/crates/matrix-sdk-base/src/client.rs
Lines 543 to 549 in 84a5d45
Though the rule is for this lock to be acquired whenever we'd like to write to the state store. It mainly protects the
RoomInfofrom being mutated by two places at the same time.This used to be fine, as we had very few places where we would modify the
RoomInfo, i.e. the sync used to be the only such place.Now the
RoomInfooperates in a copy-on-write manner. This allows us to process the sync in peace without having to block users from accessing theRoomInfo. We do this with theclone_info()method:matrix-rust-sdk/crates/matrix-sdk-base/src/room/room_info.rs
Lines 88 to 91 in 84a5d45
This setup makes it quite easy to mess things up, people need to remember that the lock needs to be taken, furthermore it needs to be taken before any
clone_info()calls.Proposed solution
Since we don't want to get rid of the copy-on-write properties, I propose that the state store lock, gives out a token of some sort.
This token must be used in the
clone_info()method. This prevents users to clone the info without taking the state store lock.The token can be a simple unit struct which the state store lock now protects.