diff options
| author | Mark Rousskov <mark.simulacrum@gmail.com> | 2022-02-07 11:03:51 -0500 |
|---|---|---|
| committer | Mark Rousskov <mark.simulacrum@gmail.com> | 2022-02-08 18:49:55 -0500 |
| commit | e240783a4d22c1e56b101ab230bee0b821065bd5 (patch) | |
| tree | c7093199316fffe10e02e03a567a748f93bbdcee /library/std/src/sys/unix/stack_overflow.rs | |
| parent | 88fb06a1f331926bccb448acdb52966fd1ec8a92 (diff) | |
| download | rust-e240783a4d22c1e56b101ab230bee0b821065bd5.tar.gz rust-e240783a4d22c1e56b101ab230bee0b821065bd5.zip | |
Switch QueryJobId to a single global counter
This replaces the per-shard counters with a single global counter, simplifying the JobId struct down to just a u64 and removing the need to pipe a DepKind generic through a bunch of code. The performance implications on non-parallel compilers are likely minimal (this switches to `Cell<u64>` as the backing storage over a `u64`, but the latter was already inside a `RefCell` so it's not really a significance divergence). On parallel compilers, the cost of a single global u64 counter may be more significant: it adds a serialization point in theory. On the other hand, we can imagine changing the counter to have a thread-local component if it becomes worrisome or some similar structure. The new design is sufficiently simpler that it warrants the potential for slight changes down the line if/when we get parallel compilation to be more of a default. A u64 counter, instead of u32 (the old per-shard width), is chosen to avoid possibly overflowing it and causing problems; it is effectively impossible that we would overflow a u64 counter in this context.
Diffstat (limited to 'library/std/src/sys/unix/stack_overflow.rs')
0 files changed, 0 insertions, 0 deletions
