You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This crate provides an async version of [`std`]. It provides all the interfaces you are used to, but in an async version and ready for Rust's `async/await`-syntax.
9
+
This crate provides an async version of [`std`]. It provides all the interfaces you
10
+
are used to, but in an async version and ready for Rust's `async`/`await` syntax.
Copy file name to clipboardExpand all lines: docs/src/concepts/tasks.md
+51-4Lines changed: 51 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -60,21 +60,68 @@ For now, it is enough to know that once you `spawn`ed a task, it will continue r
60
60
Tasks in `async_std` are one of the core abstractions. Much like Rust’s `thread`s, they provide some practical functionality over the raw concept. `Tasks` have a relationship to the runtime, but they are in themselves separate. `async_std` tasks have a number of desirable properties:
61
61
62
62
63
-
- They are single-allocated
63
+
- They are allocated in one single allocation
64
64
- All tasks have a *backchannel*, which allows them to propagate results and errors to the spawning task through the `JoinHandle`
65
65
- The carry desirable metadata for debugging
66
66
- They support task local storage
67
67
68
-
`async_std`s task api handles setup and teardown of a backing runtime for you and doesn’t rely on a runtime being started.
68
+
`async_std`s task api handles setup and teardown of a backing runtime for you and doesn’t rely on a runtime being started.
69
69
70
70
## Blocking
71
71
72
-
TODO: fill me in
72
+
`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 Rusts stdlib 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 they concurrent execution model of `async-std`. Essentially, never do this:
73
+
74
+
```rust
75
+
fnmain() {
76
+
task::block_on(async {
77
+
// this is std::fs, which blocks
78
+
std::fs::read_to_string("test_file");
79
+
})
80
+
}
81
+
```
82
+
83
+
If you want to mix operation kinds, consider putting such operations on a `thread`.
73
84
74
85
## Errors and panics
75
86
76
-
TODO: fill me in
87
+
`Task`s report errors through normal channels: If they are fallible, their `Output` should be of kind `Result<T,E>`.
88
+
89
+
In case of `panic`, behaviour differs depending on if there's a reasonable part that addresses the `panic`. If not, the program _aborts_.
90
+
91
+
In practice, that means that `block_on` propagates panics to the blocking component:
92
+
93
+
```rust
94
+
fnmain() {
95
+
task::block_on(async {
96
+
panic!("test");
97
+
});
98
+
}
99
+
```
100
+
101
+
```
102
+
thread 'async-task-driver' panicked at 'test', examples/panic.rs:8:9
103
+
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
104
+
```
105
+
106
+
While panicing a spawned tasks will abort:
107
+
108
+
```rust
109
+
task::spawn(async {
110
+
panic!("test");
111
+
});
112
+
113
+
task::block_on(async {
114
+
task::sleep(Duration::from_millis(10000)).await;
115
+
})
116
+
```
117
+
118
+
```
119
+
thread 'async-task-driver' panicked at 'test', examples/panic.rs:8:9
120
+
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
121
+
Aborted (core dumped)
122
+
```
77
123
124
+
That might seem odd at first, but the other option would be to silently ignore panics in spawned tasks. The current behaviour can be changed by catching panics in the spawned task and reacting with custom behaviour. This gives users the choice of panic handling strategy.
Copy file name to clipboardExpand all lines: docs/src/security/policy.md
+33-4Lines changed: 33 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,14 +2,12 @@
2
2
3
3
Safety is one of the core principles of what we do, and to that end, we would like to ensure that async-std has a secure implementation. Thank you for taking the time to responsibly disclose any issues you find.
4
4
5
-
All security bugs in async-std distribution should be reported by email to security@ferrous-systems.com. This list is delivered to a small security team. Your email will be acknowledged within 24 hours, and you’ll receive a more detailed response to your email within 48 hours indicating the next steps in handling your report. If you would like, you can encrypt your report using our public key. This key is also On MIT’s keyserver and reproduced below.
5
+
All security bugs in async-std distribution should be reported by email to florian.gilcher@ferrous-systems.com. This list is delivered to a small security team. Your email will be acknowledged within 24 hours, and you’ll receive a more detailed response to your email within 48 hours indicating the next steps in handling your report. If you would like, you can encrypt your report using our public key. This key is also On MIT’s keyserver and reproduced below.
6
6
7
7
Be sure to use a descriptive subject line to avoid having your report be missed. After the initial reply to your report, the security team will endeavor to keep you informed of the progress being made towards a fix and full announcement. As recommended by [RFPolicy][rf-policy], these updates will be sent at least every five days. In reality, this is more likely to be every 24-48 hours.
8
8
9
9
If you have not received a reply to your email within 48 hours, or have not heard from the security team for the past five days, there are a few steps you can take (in order):
10
10
11
-
* Contact the current security coordinator TODO directly.
12
-
* Contact the back-up contact TODO directly.
13
11
* Post on our Community forums
14
12
15
13
Please note that the discussion forums are public areas. When escalating in these venues, please do not discuss your issue. Simply say that you’re trying to get a hold of someone from the security team.
@@ -34,4 +32,35 @@ This policy is adapted from the [Rust project](https://www.rust-lang.org/policie
0 commit comments