forked from mirror/async-std
Typos and sentence structure fixes
This commit is contained in:
parent
ec23632f3e
commit
88558eae6e
4 changed files with 6 additions and 10 deletions
|
@ -24,11 +24,7 @@ To sum up: Rust gives us the ability to safely abstract over important propertie
|
|||
|
||||
## An easy view of computation
|
||||
|
||||
While computation is a subject to write a whole [book](https://computationbook.com/) about, a very simplified view suffices for us:
|
||||
|
||||
- computation is a sequence of composable operations
|
||||
- they can branch based on a decision
|
||||
- they either run to succession and yield a result, or they can yield an error
|
||||
While computation is a subject to write a whole [book](https://computationbook.com/) about, a very simplified view suffices for us: A sequence of composable operations which can branch based on a decision, run to succession and yield a result or yield an error
|
||||
|
||||
## Deferring computation
|
||||
|
||||
|
@ -136,11 +132,11 @@ When executing 2 or more of these functions at the same time, our runtime system
|
|||
|
||||
## Conclusion
|
||||
|
||||
Working from values, we searched for something that expresses *working towards a value available sometime later*. From there, we talked about the concept of polling.
|
||||
Working from values, we searched for something that expresses *working towards a value available later*. From there, we talked about the concept of polling.
|
||||
|
||||
A `Future` is any data type that does not represent a value, but the ability to *produce a value at some point in the future*. Implementations of this are very varied and detailed depending on use-case, but the interface is simple.
|
||||
|
||||
Next, we will introduce you to `tasks`, which we need to actually *run* Futures.
|
||||
Next, we will introduce you to `tasks`, which we will use to actually *run* Futures.
|
||||
|
||||
[^1]: Two parties reading while it is guaranteed that no one is writing is always safe.
|
||||
|
||||
|
|
|
@ -80,7 +80,7 @@ Tasks in `async_std` are one of the core abstractions. Much like Rust's `thread`
|
|||
|
||||
## Blocking
|
||||
|
||||
`Task`s are assumed to run _concurrently_, potentially by sharing a thread of execution. This means that operations blocking an _operating system thread_, such as `std::thread::sleep` or io function from Rust's `std` library will _stop execution of all tasks sharing this thread_. Other libraries (such as database drivers) have similar behaviour. Note that _blocking the current thread_ is not in and by itself bad behaviour, just something that does not mix well with the concurrent execution model of `async-std`. Essentially, never do this:
|
||||
`Task`s are assumed to run _concurrently_, potentially by sharing a thread of execution. This means that operations blocking an _operating system thread_, such as `std::thread::sleep` or io function from Rust's `std` library will _stop execution of all tasks sharing this thread_. Other libraries (such as database drivers) have similar behaviour. Note that _blocking the current thread_ is not in and of itself bad behaviour, just something that does not mix well with the concurrent execution model of `async-std`. Essentially, never do this:
|
||||
|
||||
```rust,edition2018
|
||||
# extern crate async_std;
|
||||
|
|
|
@ -4,4 +4,4 @@
|
|||
|
||||
`async-std` provides an interface to all important primitives: filesystem operations, network operations and concurrency basics like timers. It also exposes a `task` in a model similar to the `thread` module found in the Rust standard lib. But it does not only include I/O primitives, but also `async/await` compatible versions of primitives like `Mutex`.
|
||||
|
||||
[organization]: https://github.com/async-rs/async-std
|
||||
[organization]: https://github.com/async-rs
|
||||
|
|
|
@ -31,7 +31,7 @@ In general, this crate will be conservative with respect to the minimum supporte
|
|||
|
||||
## Security fixes
|
||||
|
||||
Security fixes will be applied to _all_ minor branches of this library in all _supported_ major revisions. This policy might change in the future, in which case we give at least _3 month_ of ahead notice.
|
||||
Security fixes will be applied to _all_ minor branches of this library in all _supported_ major revisions. This policy might change in the future, in which case we give at least _3 months_ of ahead.
|
||||
|
||||
## Credits
|
||||
|
||||
|
|
Loading…
Reference in a new issue