Blog post alpha 2 #1134

MajorBreakfast · 2018-07-27T14:38:47Z

Do not merge.

Comments are welcome!

MajorBreakfast · 2018-07-27T14:41:37Z

@cramertj I tried to give an overview over what Try does for Poll. Can you look it over?
@tinaun @Nemo157 @aturon Is everything I say about the compatibility layer right?

aturon · 2018-07-27T14:46:12Z

_posts/2018-01-01-futures-0.3.0-alpha.2.md

+
+### Compatiblity layer for futures 0.1
+
+We are currently working on an officially supported compatibility layer between `0.1` and `0.3`. This shim will make it possible to mix `0.1` futures with those from the 0.3 branch. The plan is to make it possible to use crates from the existing futures `0.1` ecosystem together with async functions and futures from the `0.3` crate. Additionally, this compatibility layer will also make it possible to gradually migrate exisiting applications and libraries to `0.3`. If you're curious, take a look the the [compatibility layer PR](https://github.com/rust-lang-nursery/futures-rs/pull/1119).


Maybe link to the WG-net issue as well?

aturon

This looks fantastic! 💯

Nemo157 · 2018-07-27T15:12:46Z

👍 compatibility layer stuff looks good, we can get some more details onto the tracking issue instead of cluttering the blog posts until we have some good examples ready.

MajorBreakfast · 2018-07-27T15:49:33Z

@Nemo157 Exactly what I had in mind. I think the blog should always only present things that work already.

cramertj · 2018-07-27T16:43:19Z

_posts/2018-01-01-futures-0.3.0-alpha.2.md

+
+> Futures are polled until completion by tasks, a kind of lightweight "thread". A *task executor* is responsible for the creation of these tasks and the coordination of their execution on real operating system threads. In particular, whenever a task signals that it can make further progress via a wake-up notification, it is the responsibility of the task executor to put the task into a queue to continue executing it, i.e. polling the future in it, later.
+
+The notable difference to before is that the term "task" no longer refers to the future that the task runs. Instead, from now on, the term "task" only refers to the concept of a "lightweight" thread, a kind of thread that doesn't directly correspond to a thread provided by the operating system. This concept is sometimes also referred to as "green thread" - We, however, do not use either these terms because they tend to cause confusion with real operating system threads. Instead, we call this concept a "task" and the thing that runs them "task executor" or often just "executor".


Nit: no parens needed around "lightweight" thread

Those are quotes 😉 - I'll remove them

something something "technically correct == the best kind of correct"

cramertj · 2018-07-27T16:46:08Z

_posts/2018-01-01-futures-0.3.0-alpha.2.md

+```
+
+- The `?`-operator used on a `Poll<Result<T, E>>` value:
+  - yields `Poll::Pending` from the expression if the value is not ready.


"yields" is confusing here-- maybe something like

"When ? is used on a Poll<Result<T, E>> or a Poll<Option<Result<T, E>>> containing an Err value, it will return early. If the expression does not contain an error, it will result in a Poll<T> or Poll<Option<T>>, respectively."

cramertj · 2018-07-27T16:46:24Z

_posts/2018-01-01-futures-0.3.0-alpha.2.md

+  - returns `Poll::Ready(Err(err_value))` from the function if the value is ready and an error.
+- The `ready!` macro used on a `Poll<T>` value:
+  - yields the value of type `T` from the expression if the value is ready.
+  - returns `Poll::pending` from the function if the value is not ready.


Nit: capitalize "pending"

cramertj · 2018-07-27T16:47:17Z

_posts/2018-01-01-futures-0.3.0-alpha.2.md

+  - yields the value of type `T` from the expression if the value is ready.
+  - returns `Poll::pending` from the function if the value is not ready.
+
+Additionally `Try` was also implemented for `Poll<Option<Result<T, E>>>`, more details on that in the [pull request](https://github.com/rust-lang/rust/pull/52721).


Maybe say something like "so now ?" can be used in manual implementations and uses of Futures and Streams."

cramertj · 2018-07-27T21:01:46Z

_posts/2018-01-01-futures-0.3.0-alpha.2.md

+```
+
+- The `?`-operator used on a `Poll<Result<T, E>>` behaves like this:
+  - If there is an error, it early returns `Poll::Ready(Err(err))`


s/"early returns"/"returns early with" or just "returns"

cramertj · 2018-07-27T21:02:15Z

_posts/2018-01-01-futures-0.3.0-alpha.2.md

+
+- The `?`-operator used on a `Poll<Result<T, E>>` behaves like this:
+  - If there is an error, it early returns `Poll::Ready(Err(err))`
+  - Otherwise, it gives back the `Poll<T>` value, i.e. either `Poll::Pending` or `Poll::Ready(val)`


cramertj · 2018-07-27T21:03:25Z

_posts/2018-01-01-futures-0.3.0-alpha.2.md

+  - Otherwise, it gives back the `Poll<T>` value, i.e. either `Poll::Pending` or `Poll::Ready(val)`
+
+- The `ready!` macro used on a `Poll<T>` value behaves like this:
+  - If the value not ready, it early returns `Poll::Pending`


s/"the value not ready"/"the value is pending"
s/'It early returns"/"it returns early with"

cramertj · 2018-07-27T21:03:45Z

_posts/2018-01-01-futures-0.3.0-alpha.2.md

+  - If the value not ready, it early returns `Poll::Pending`
+  - Otherwise, it gives back the value of type `T`
+
+Additionally `Try` was also implemented for `Poll<Option<Result<T, E>>>` to make the `?`-operator useful in `Stream::poll` method implentations as well:


s/as well//

cramertj · 2018-07-27T22:09:21Z

aturon reviewed Jul 27, 2018

View reviewed changes

aturon approved these changes Jul 27, 2018

View reviewed changes

MajorBreakfast force-pushed the blog-alpha-2 branch 9 times, most recently from 9bd7d01 to db300d6 Compare July 27, 2018 15:00

cramertj reviewed Jul 27, 2018

View reviewed changes

MajorBreakfast force-pushed the blog-alpha-2 branch from db300d6 to 57d74f6 Compare July 27, 2018 20:56

cramertj reviewed Jul 27, 2018

View reviewed changes

MajorBreakfast force-pushed the blog-alpha-2 branch from 57d74f6 to 1eb6c51 Compare July 27, 2018 22:06

MajorBreakfast force-pushed the blog-alpha-2 branch 3 times, most recently from ae93e26 to ee2cfc5 Compare July 28, 2018 11:15

MajorBreakfast force-pushed the gh-pages branch from b966ead to fe223a7 Compare July 30, 2018 09:51

Blog post alpha 2

50ea6de

MajorBreakfast force-pushed the blog-alpha-2 branch from ee2cfc5 to 50ea6de Compare July 30, 2018 11:28

MajorBreakfast merged commit ae99a3a into rust-lang:gh-pages Jul 30, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Blog post alpha 2 #1134

Blog post alpha 2 #1134

MajorBreakfast commented Jul 27, 2018 •

edited

Loading

MajorBreakfast commented Jul 27, 2018 •

edited

Loading

aturon Jul 27, 2018

aturon left a comment

Nemo157 commented Jul 27, 2018

MajorBreakfast commented Jul 27, 2018

cramertj Jul 27, 2018

MajorBreakfast Jul 27, 2018

cramertj Jul 27, 2018

cramertj Jul 27, 2018

cramertj Jul 27, 2018

cramertj Jul 27, 2018

cramertj Jul 27, 2018 •

edited

Loading

cramertj Jul 27, 2018

cramertj Jul 27, 2018

cramertj Jul 27, 2018

cramertj commented Jul 27, 2018


		### Compatiblity layer for futures 0.1

		We are currently working on an officially supported compatibility layer between `0.1` and `0.3`. This shim will make it possible to mix `0.1` futures with those from the 0.3 branch. The plan is to make it possible to use crates from the existing futures `0.1` ecosystem together with async functions and futures from the `0.3` crate. Additionally, this compatibility layer will also make it possible to gradually migrate exisiting applications and libraries to `0.3`. If you're curious, take a look the the [compatibility layer PR](https://github.com/rust-lang-nursery/futures-rs/pull/1119).


		> Futures are polled until completion by tasks, a kind of lightweight "thread". A task executor is responsible for the creation of these tasks and the coordination of their execution on real operating system threads. In particular, whenever a task signals that it can make further progress via a wake-up notification, it is the responsibility of the task executor to put the task into a queue to continue executing it, i.e. polling the future in it, later.

		The notable difference to before is that the term "task" no longer refers to the future that the task runs. Instead, from now on, the term "task" only refers to the concept of a "lightweight" thread, a kind of thread that doesn't directly correspond to a thread provided by the operating system. This concept is sometimes also referred to as "green thread" - We, however, do not use either these terms because they tend to cause confusion with real operating system threads. Instead, we call this concept a "task" and the thing that runs them "task executor" or often just "executor".

Blog post alpha 2 #1134

Blog post alpha 2 #1134

Conversation

MajorBreakfast commented Jul 27, 2018 • edited Loading

MajorBreakfast commented Jul 27, 2018 • edited Loading

Choose a reason for hiding this comment

aturon left a comment

Choose a reason for hiding this comment

Nemo157 commented Jul 27, 2018

MajorBreakfast commented Jul 27, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cramertj Jul 27, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cramertj commented Jul 27, 2018

MajorBreakfast commented Jul 27, 2018 •

edited

Loading

MajorBreakfast commented Jul 27, 2018 •

edited

Loading

cramertj Jul 27, 2018 •

edited

Loading