async usage of svm-rs

[rkrasiuk]

Is your feature request related to a problem? Please describe.
usage of svm-rs with a blocking feature inside a tokio runtime leads to the following error
Cannot drop a runtime in a context where blocking is not allowed. This happens when a runtime is dropped from within an asynchronous context.
reqwest::blocking doesn't behave well inside another tokio rt

Describe the solution you'd like
use svm async threadbound

cc @mattsse

[mattsse]

this is unfortunatelly a limitation of reqwest::blocking

what we could do

1. use svm-async within

 runtime::Builder::new_current_thread()
                .enable_io()
                .build().unwrap().block_on(async {svm::install})

2. try accessing the Handle or create a new multithreaded rt

actually not sure about the performance benefits of 2 over 1

[gakonst]

OK makes sense, so reqwest::blocking doesn't behave well in Tokio environments, would have been nice if it did.

I think let's go with:

1. https://github.com/foundry-rs/foundry/blob/master/utils/src/lib.rs#L27-L54 move this over to ethers-solc (and expose it so we can import it in foundry)
2. Use RuntimeOrHandle::new().block_on(...) for the 2 fns where blocking_install is called:

   • ethers-rs/ethers-solc/src/resolver/mod.rs

     Line 724 in eb94e53

     Solc::blocking_install(version.as_ref())?

   • ethers-rs/ethers-solc/src/resolver/mod.rs

     Line 742 in eb94e53

     Solc::blocking_install(version.as_ref())?;

@mattsse mentioned there might be some performance change if using single vs multi threaded runtime, but I think this is a case where it shouldn't matter that much, given that it's a single request.

[rkrasiuk]

@gakonst and why don't we block_on the actual svm::blocking_install?

ethers-rs/ethers-solc/src/compile/mod.rs

Line 376 in eb94e53

match svm::blocking_install(version) {

[gakonst]

I guess that also works :D

[mattsse]

vote close @gakonst

[rkrasiuk]

second @mattsse. my foundry integration tests seem to be fixed