Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

check core for wasm #228

Merged
merged 14 commits into from
Apr 19, 2021
Merged

check core for wasm #228

merged 14 commits into from
Apr 19, 2021

Conversation

ctaggart
Copy link
Contributor

@ctaggart ctaggart commented Apr 11, 2021

For #37. This allows azure_core to target wasm. This builds off the http client work. It adds two features:

  • enable_request (default)
  • enable_hyper

@ctaggart
Copy link
Contributor Author

ctaggart commented Apr 11, 2021

An error I received was:

Rc<RefCell<wasm_bindgen_futures::Inner>>` cannot be sent between threads safely

Which led me to rustwasm/wasm-bindgen#2409 and then do the async_trait docs which say:

Not all async traits need futures that are dyn Future + Send. To avoid having
Send and Sync bounds placed on the async trait methods, invoke the async trait
macro as #[async_trait(?Send)] on both the trait and the impl blocks.

It worked for compiling azure_core but may cascade changes. I could use some help understanding the impact.

Copy link
Contributor Author

@ctaggart ctaggart left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It compiles. 🥳 I'm sure I broke some stuff regarding Send. Conceptually, do we need the clients implementing Send? Please review in detail.

@@ -92,7 +94,8 @@ impl HttpClient for hyper::Client<HttpsConnector<hyper::client::HttpConnector>>
}
}

#[async_trait]
#[cfg(feature = "enable_reqwest")]
#[async_trait(?Send)]
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change appears to have a cascading effect. https://docs.rs/async-trait/0.1.48/async_trait/#non-threadsafe-futures

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cfg_attr to the rescue! I've disabled Send from wasm builds only. Thanks to:
dtolnay/async-trait#159 (comment)

}
}
// TODO
// pub fn with_client(client: Arc<Box<dyn HttpClient>>) -> Self {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CosmosOption::with_client from #204 Policy Architecture does not compile now and I could use some help, @rylev.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you post the compiler error?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PS C:\Users\cataggar\io\azure-sdk-for-rust> cargo check
    Checking azure_cosmos v0.1.0 (C:\Users\cataggar\io\azure-sdk-for-rust\sdk\cosmos)
error: future cannot be sent between threads safely
  --> sdk\cosmos\src\clients\cosmos_client.rs:51:17
   |
51 |                 Box::pin(async move { Ok(client.execute_request(req).await?.into()) })
   |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ future created by async block is not `Send`
   |
   = help: the trait `std::marker::Send` is not implemented for `dyn futures::Future<Output = Result<http::Response<bytes::Bytes>, Box<dyn StdError + Sync + std::marker::Send>>>`
note: future is not `Send` as it awaits another future which is not `Send`
  --> sdk\cosmos\src\clients\cosmos_client.rs:51:42
   |
51 |                 Box::pin(async move { Ok(client.execute_request(req).await?.into()) })
   |                                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^ await occurs here on type `Pin<Box<dyn futures::Future<Output = Result<http::Response<bytes::Bytes>, Box<dyn StdError + Sync + std::marker::Send>>>>>`, which is not `Send`
   = note: required for the cast to the object type `dyn futures::Future<Output = Result<azure_core::Response, Box<(dyn StdError + Sync + std::marker::Send + 'static)>>> + std::marker::Send`

@@ -13,7 +13,7 @@ categories = ["api-bindings"]
edition = "2018"

[dependencies]
azure_core = { path = "../core", version = "0.1.0" }
azure_core = { path = "../core", version = "0.1.0", features = ["enable_hyper"] }
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm hoping this is temporary. We can create an issue to make event_grid not require hyper.

sdk/storage/tests/blob.rs Outdated Show resolved Hide resolved
sdk/storage/tests/blob.rs Outdated Show resolved Hide resolved
.github/workflows/build.yml Outdated Show resolved Hide resolved
sdk/core/src/http_client.rs Outdated Show resolved Hide resolved
@@ -122,6 +127,19 @@ impl HttpClient for reqwest::Client {
}
}

// wasm can not get the http version
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I try to use it, I get:

PS C:\Users\cataggar\io\azure-sdk-for-rust> cargo check -p azure_core --target=wasm32-unknown-unknown
    Blocking waiting for file lock on build directory
    Checking azure_core v0.1.0 (C:\Users\cataggar\io\azure-sdk-for-rust\sdk\core)
error[E0599]: no method named `version` found for reference `&reqwest::Response` in the current scope
   --> sdk\core\src\http_client.rs:140:19
    |
140 |     Some(response.version())
    |                   ^^^^^^^ method not found in `&reqwest::Response`

The code shows this:
https://github.com/seanmonstar/reqwest/blob/1614c5ea64813ba24d268a2af22ab0d19b902bdf/src/wasm/response.rs#L67-L73

    /* It might not be possible to detect this in JS?
    /// Get the HTTP `Version` of this `Response`.
    #[inline]
    pub fn version(&self) -> Version {
        self.http.version()
    }
    */

}
}
// TODO
// pub fn with_client(client: Arc<Box<dyn HttpClient>>) -> Self {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you post the compiler error?

sdk/storage/tests/blob.rs Outdated Show resolved Hide resolved
.github/workflows/build.yml Outdated Show resolved Hide resolved
Copy link
Contributor

@rylev rylev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Supporting wasm is definitely something we want. I think this needs some work though before we merge.

@MindFlavor
Copy link
Contributor

I love this ❤️!

I am not clear why we can't have Sendable async traits. Is it a wasm requirement? That seems the only big blocker required for your PR (the pipeline code is being worked on now so I won't fixate too much on it).

#[async_trait]
#[cfg(feature = "enable_reqwest")]
#[cfg_attr(target_arch = "wasm32", async_trait(?Send))]
#[cfg_attr(not(target_arch = "wasm32"), async_trait)]
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't know about cfg_attr, but thanks to dtolnay/async-trait#159 (comment), it works perfectly. Send is only disabled for wasm builds. Everything else works as before.

@ctaggart ctaggart changed the title build core for wasm check core for wasm Apr 14, 2021
Copy link
Contributor

@MindFlavor MindFlavor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems fine to me.
Nice work! 👍

@ctaggart ctaggart merged commit e1a0d62 into Azure:master Apr 19, 2021
@ctaggart ctaggart deleted the wasm_core branch April 19, 2021 15:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants