feat(client): mechanism for closing and reopening a client and its underlying stores#6495
Conversation
9963065 to
dc9bdd9
Compare
Merging this PR will not alter performance
Comparing Footnotes
|
dc9bdd9 to
487640f
Compare
andybalaam
left a comment
There was a problem hiding this comment.
This looks plausible, with one mild suggestion. I don't understand the area well, so feel free to ask someone else for more input if you want it.
|
Thanks Andy! I'll guess I'll choose... @Hywan as my next victim 😁 |
Hywan
left a comment
There was a problem hiding this comment.
Thanks for the contribution! I made a couple of suggestions, nothing huge.
Hywan
left a comment
There was a problem hiding this comment.
Approving ahead of time to save you the last review roundtrip. Thanks for the discussions!
…ementations for all the stores
…he, state and media SQLite stores
This patch implements the main pause/resume logic in the underlying SDK stores.
The in memory stores no-op trough the default trait implementations.
The main change are limited to the sqlite crate:
- a new type called `SqliteConnections` has been introduced which now holds a
store's read connection pools as well as the always on write connection. This
lives as an optional on each store's level and gets set to None whenever the
store is paused
- during the pausing phase `SqliteConnections` (through its `pause_connections`
method) does the following:
- closes the read pool, directly dropping idle connections
- waits for in flight writes to finish
- tries a best effort WAL checkpoint
- drops the write connection on a blocking thread
- and waits for in-flight read connections to drain
- this is all best effort with an eventual timeout
- resuming connections is also shared between the stores through
`SqliteConnections` and consists in building a new pool with the previous
configuration and creating a new write connection
# Conflicts:
# crates/matrix-sdk-sqlite/src/crypto_store.rs
# crates/matrix-sdk-sqlite/src/event_cache_store.rs
# crates/matrix-sdk-sqlite/src/media_store.rs
# crates/matrix-sdk-sqlite/src/state_store.rs
64175f0 to
0329514
Compare
This patch exposes the pause/resume mechanism for SDK stores all the way up to the FFI `Client`, so apps can temporarily release SQLite resources when moving to the background and re-acquire them on resume. The main use case is iOS backgrounding, where keeping SQLite file descriptors and locks open can contribute to `0xdead10cc` terminations by the operating system.
0329514 to
aaa7017
Compare
…eplace them with concrete ones.
b75101e to
9f70dba
Compare
This patch exposes the pause/resume mechanism for SDK stores all the way up to the FFI
Client, so apps can temporarily release SQLite resources when moving to the background and re-acquire them on resume.The main use case is iOS backgrounding, where keeping SQLite file descriptors and locks open can contribute to
0xdead10ccterminations by the operating system.The main change are limited to the sqlite crate with in memory stores no-oping trough the default trait implementations:
SqliteConnectionshas been introduced which now holds a store's read connection pools as well as the always on write connection. This lives as an optional on each store's level and gets set to None whenever the store is pausedSqliteConnections(through itspause_connectionsmethod) does the following:SqliteConnectionsand consists in building a new pool with the previous configuration and creating a new write connectionHandles #6366
Event with this in place though the client side isn't entirely straight forward as the sync service, send queue and pause/resume mechanisms still need to be coordinator in the right order. A better solution would be the to incorporate all of those within an app specific service on the rust side (which we've talked about multiple times over the years) and let the SDK coordinate them instead.