zcash_client_backend: Allow sharing instances of ScanningKeys between threads
#1400
Conversation
Bound `ScanningKeyOps` by `Send + Sync` so `ScanningKeys` auto-implements `Send` and `Sync` instead of `!Send` and `!Sync`.
upbqdn
force-pushed
the
scanning_keys_send
branch
from
9669142
to
99dfbb9
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1400 +/- ##
=======================================
Coverage 63.13% 63.13%
=======================================
Files 126 126
Lines 14720 14720
=======================================
Hits 9293 9293
Misses 5427 5427 ☔ View full report in Codecov by Sentry. |
| @@ -120,7 +120,7 @@ pub struct ScanningKey<Ivk, Nk, AccountId> { | |||
| key_scope: Option<Scope>, | |||
| } | |||
|
|
|||
| impl<AccountId> ScanningKeyOps<SaplingDomain, AccountId, sapling::Nullifier> | |||
| impl<AccountId: Send + Sync> ScanningKeyOps<SaplingDomain, AccountId, sapling::Nullifier> | |||
There was a problem hiding this comment.
Is this bound (repeated everywhere) avoidable if we add the equivalent bound on AccountId in ScanningKeyOps?
There was a problem hiding this comment.
Unfortunately, to be able to move an instance of ScannningKeys to tokio::task::spawn_blocking for example, the compiler requires Send and Sync to be implemented for ScanningKeyOps. Otherwise, I get this error:
`(dyn ScanningKeyOps<sapling_crypto::note_encryption::SaplingDomain, AccountId, sapling_crypto::note::nullifier::Nullifier> + 'static)` cannot be sent between threads safelyI tried bounding AccountId by Send and Sync in ScanningKeyOps, but that didn't help.
Bounding ScanningKeyOps itself eliminates the error, but once I do that, I have to make the rest of the changes in this PR to fix subsequent bound requirements.
There was a problem hiding this comment.
This PR is not important though, feel free to close it without merging if it's of no use. The workaround was to create an instance of ScanningKeys in the scanning thread itself. Moreover, we have no plans to work on the scanner any time soon.
Motivation
It would be handy if Zebra could share instances of
ScanningKeysbetween threads.Solution
ScanningKeyOpsbySend + SyncsoScanningKeysauto-implementsSendandSyncinstead of!Sendand!Sync.