We don't want to block other tasks on backup operations. We can increase the number of used thread in tokio runtime to the default (the number of cores of the system) so other operations can still proceed. This shouldn't cause a problem for NSE (there were worries that too many threads could make the notifications less likely to be delivered) because rust_native_library isn't even compiled for the notification service.
Details
Details
Test that the app runs on physical iOS and Android devices
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
| native/native_rust_library/src/lib.rs | ||
|---|---|---|
| 42 | Treat this comment as a food for thought rather than something you should strictly answer before proceeding with this diff.
| |
| native/native_rust_library/src/lib.rs | ||
|---|---|---|
| 42 | For 1,2 I feel like this is a higher-level issues and will be largely solved at the js-level. If we are in restoration mode, the app can't really do anything else, this is a blocking operation. Running backup upload operations should be synchronized with other app operations by either using the GlobalDBSigleton or other synchronization methods (e.g. previously we were thinking about using files for log synchronization). For 1 tokio exposes something called blocking threads, spawn_blocking. In particular:
So we could put the encryption operations inside it, especially when they become larger (right now, for the testing code it's just user store). One issue is that they are mostly to spawn *from async* code and not the other way around. I think it might make to wait for the rest of the networking client to decide how to use them exactly (as networking will be async-based) to see how the code will be structured. | |