From e9e3754402f6f4e1b7f16bf5f6c0e050eb473bc6 Mon Sep 17 00:00:00 2001 From: Stjepan Glavina Date: Sun, 18 Aug 2019 19:14:27 +0200 Subject: [PATCH 1/2] Add Surf example (#78) * Add Surf example * Use a different osx image --- .travis.yml | 1 + Cargo.toml | 1 + examples/surf-web.rs | 21 +++++++++++++++++++++ 3 files changed, 23 insertions(+) create mode 100644 examples/surf-web.rs diff --git a/.travis.yml b/.travis.yml index f41138f0..bc25dc67 100644 --- a/.travis.yml +++ b/.travis.yml @@ -14,6 +14,7 @@ matrix: env: BUILD_DOCS=1 - rust: nightly os: osx + osx_image: xcode9.2 env: BUILD_DOCS=1 - rust: nightly-x86_64-pc-windows-msvc os: windows diff --git a/Cargo.toml b/Cargo.toml index 99b76bb4..70ae2541 100644 --- a/Cargo.toml +++ b/Cargo.toml @@ -36,6 +36,7 @@ mio-uds = "0.6.7" num_cpus = "1.10.0" pin-utils = "0.1.0-alpha.4" slab = "0.4.2" +surf = "1.0.1" [dev-dependencies] femme = "1.1.0" diff --git a/examples/surf-web.rs b/examples/surf-web.rs new file mode 100644 index 00000000..7581edbd --- /dev/null +++ b/examples/surf-web.rs @@ -0,0 +1,21 @@ +//! Sends an HTTP request to the Rust website. + +#![feature(async_await)] + +use async_std::task; + +fn main() -> Result<(), surf::Exception> { + task::block_on(async { + let url = "https://www.rust-lang.org"; + let mut response = surf::get(url).await?; + let body = response.body_string().await?; + + dbg!(url); + dbg!(response.status()); + dbg!(response.version()); + dbg!(response.headers()); + dbg!(body.len()); + + Ok(()) + }) +} From ed81a9e23c33502a429d3bbdb2d8c4568370ad80 Mon Sep 17 00:00:00 2001 From: Wesley Moore Date: Mon, 19 Aug 2019 17:10:28 +1000 Subject: [PATCH 2/2] Fix a couple of typos in the book --- docs/src/concepts/futures.md | 2 +- docs/src/concepts/tasks.md | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/src/concepts/futures.md b/docs/src/concepts/futures.md index 2eea1469..d481023e 100644 --- a/docs/src/concepts/futures.md +++ b/docs/src/concepts/futures.md @@ -10,7 +10,7 @@ Luckily, concurrent Rust already has two well-known and effective concepts abstr As a quick summary: -- `Send` abstracts over *passing data* in a computation to another concurrent computation (let's call it the receiver), losing access to it on the sender side. In many programming languages, this strategy is commonly implemented, but missing support from the language side expects you to enforce the "losing access" behaviour yourself. This is a regular source of bugs: senders keeping handles to sent things around and maybe even working with them after sending. Rust mitigates this problem by making this behaviour known. Types can be `Send` or not (by implementing the appropriate marker trait), allowing or disallowing sending them around, and the ownership and borrowing rules prevent subsequent access. +- `Send` abstracts over *passing data* in a computation to another concurrent computation (let's call it the receiver), losing access to it on the sender side. In many programming languages, this strategy is commonly implemented, but missing support from the language side, and expects you to enforce the "losing access" behaviour yourself. This is a regular source of bugs: senders keeping handles to sent things around and maybe even working with them after sending. Rust mitigates this problem by making this behaviour known. Types can be `Send` or not (by implementing the appropriate marker trait), allowing or disallowing sending them around, and the ownership and borrowing rules prevent subsequent access. - `Sync` is about *sharing data* between two concurrent parts of a program. This is another common pattern: as writing to a memory location or reading while another party is writing is inherently unsafe, this access needs to be moderated through synchronisation.[^1] There are many common ways for two parties to agree on not using the same part in memory at the same time, for example mutexes and spinlocks. Again, Rust gives you the option of (safely!) not caring. Rust gives you the ability to express that something *needs* synchronisation while not being specific about the *how*. diff --git a/docs/src/concepts/tasks.md b/docs/src/concepts/tasks.md index 22921530..d8c71c98 100644 --- a/docs/src/concepts/tasks.md +++ b/docs/src/concepts/tasks.md @@ -63,10 +63,10 @@ Tasks in `async_std` are one of the core abstractions. Much like Rust's `thread` - They are allocated in one single allocation - All tasks have a *backchannel*, which allows them to propagate results and errors to the spawning task through the `JoinHandle` -- The carry useful metadata for debugging +- They carry useful metadata for debugging - They support task local storage -`async_std`s task api handles setup and teardown of a backing runtime for you and doesn't rely on a runtime being explicitly started. +`async_std`s task API handles setup and teardown of a backing runtime for you and doesn't rely on a runtime being explicitly started. ## Blocking