blob: 17b11ea79297d2995e2c48c92fc43c5cc4f803bb (
plain)
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
70
71
72
|
<!--
Copyright (C) Daniel Stenberg, <daniel@haxx.se>, et al.
SPDX-License-Identifier: curl
-->
# Multi Identifiers (mid)
All transfers (easy handles) added to a multi handle are assigned
a unique identifier until they are removed again. The multi handle
keeps a table `multi->xfers` that allow O(1) access to the easy
handle by its `mid`.
References to other easy handles *should* keep their `mid`s instead
of a pointer (not all code has been converted as of now). This solves
problems in easy and multi handle life cycle management as well as
iterating over handles where operations may add/remove other handles.
### Values and Lifetime
An `mid` is an `unsigned int`. There are two reserved values:
* `0`: is the `mid` of an internal "admin" handle. Multi and share handles
each have their own admin handle for maintenance operations, like
shutting down connections.
* `UINT_MAX`: the "invalid" `mid`. Easy handles are initialized with
this value. They get it assigned again when removed from
a multi handle.
This makes potential range of `mid`s from `1` to `UINT_MAX - 1` *inside
the same multi handle at the same time*. However, the `multi->xfers` table
reuses `mid` values from previous transfers that have been removed.
`multi->xfers` is created with an initial capacity. At the time of this
writing that is `16` for "multi_easy" handles (used in `curl_easy_perform()`
and `512` for multi handles created with `curl_multi_init()`.
The first added easy handle gets `mid == 1` assigned. The second one receives `2`,
even when the fist one has been removed already. Every added handle gets an
`mid` one larger than the previously assigned one. Until the capacity of
the table is reached and it starts looking for a free id at `1` again (`0`
is always in the table).
When adding a new handle, the multi checks the amount of free entries
in the `multi->xfers` table. If that drops below a threshold (currently 25%),
the table is resized. This serves two purposes: one, a previous `mid` is not
reused immediately and second, table resizes are not needed that often.
The table is implemented in `uint-table.[ch]`. More details in [`UINT_SETS`](UINT_SETS.md).
### Tracking `mid`s
There are several places where transfers need to be tracked:
* the multi tracks `process`, `pending` and `msgsent` transfers. A transfer
is in at most one of these at a time.
* connections track the transfers that are *attached* to them.
* multi event handling tracks transfers interested in a specific socket.
* DoH handles track the handle they perform lookups for (and vice versa).
There are two bitset implemented for storing `mid`s: `uint_bset` and `uint_spbset`.
The first is a bitset optimal for storing a large number of unsigned int values.
The second one is a "sparse" variant good for storing a small set of numbers.
More details about these in [`UINT_SETS`](UINT_SETS.md).
A multi uses `uint_bset`s for `process`, `pending` and `msgsent`. Connections
and sockets use the sparse variant as both often track only a single transfer
and at most 100 on an HTTP/2 or HTTP/3 connection/socket.
These sets allow safe iteration while being modified. This allows a multi
to iterate over its "process" set while existing transfers are removed
or new ones added.
|
