1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
//! The in-flight table: what a request id names, and what states it passes
//! through.
use HashMap;
use ;
/// Names one request for as long as its host tracks it.
///
/// **Never reused**, for the reason `blitz-wasm` gives for handles and listener
/// ids: a stale id must be an error rather than a silent hit on whatever took
/// its place. A guest that releases a request and then reads it gets
/// [`FetchState::Unknown`], not another request's body.
///
/// A `u64` here. A binding that has to return this to a guest through a
/// negative-is-error `i32` has a narrower range to work with, and capping it is
/// that binding's business, not this crate's.
;
/// Where a request has got to.
/// What the table holds per id.
///
/// The answer is boxed because a [`FetchResponse`] carries a `Url`, a
/// `HeaderMap` and a `Bytes`, and without the box every *pending* entry would
/// reserve room for all three. A page that starts a hundred requests holds a
/// hundred of these, and the whole point of the table is that pending is the
/// cheap state.
pub
/// Every request one host knows about.
///
/// A `HashMap` rather than a `Vec` indexed by id, because ids are never reused:
/// a vector would keep growing across a long-lived document even as requests
/// are released.
pub