Use Multi threaded runtime in sync_wallets
#213
Conversation
This is needed since so that components(such as `KVStore`) can use `block_in_place`. `block_in_place` is only allowed inside a multi-threaded runtime. `sync_wallets` internally syncs channel_manager and chain_monitor which results in persistence using `KVStore`. Using blocking `sync_wallets` should be avoided but is mostly used in functional_tests.
There was a problem hiding this comment.
Ugh, yeah, I was running into this before, too when working on #152. However, luckily I generally found a cleaner way around using block_on with #205.
I think it's fine to go ahead with this for now, but generally I really dislike the all the complexity that comes with stacking different runtimes on top of each other.
E.g., IIUC in this example the block_in_place of VssStore would here let the outer runtime spawn a new worker thread (which is why it needs to be multi-threaded), but then the actual task will be spawned on VssStore's internal runtime.
@G8XSU I think I had brought this up briefly before, but could we consider also exposing a blocking variant of VssClient (switchable via feature as we do it for example for EsploraSyncClient) and use the blocking variant in VssStore until we get proper async KVStore interfaces in LDK?
This is needed since so that components(such as
KVStore) can useblock_in_place.block_in_placeis only allowed inside a multi-threaded runtime.sync_walletsinternally syncs channel_manager and chain_monitor which results in persistence usingKVStore.Using blocking
sync_walletsshould be avoided but is mostly used in functional_tests.