about summary refs log tree commit diff
path: root/library/std/src/sys/unix/stack_overflow.rs
diff options
context:
space:
mode:
authorbors <bors@rust-lang.org>2022-02-09 18:54:30 +0000
committerbors <bors@rust-lang.org>2022-02-09 18:54:30 +0000
commite7aca895980f25f6d2d3c48e10fd04656764d1e4 (patch)
treede43c5fec1068ec200630000837d4bfcaeacd054 /library/std/src/sys/unix/stack_overflow.rs
parent9747ee4755e6e3c4b4b4c7a0587df29123835cda (diff)
parente240783a4d22c1e56b101ab230bee0b821065bd5 (diff)
downloadrust-e7aca895980f25f6d2d3c48e10fd04656764d1e4.tar.gz
rust-e7aca895980f25f6d2d3c48e10fd04656764d1e4.zip
Auto merge of #93741 - Mark-Simulacrum:global-job-id, r=cjgillot
Refactor query system to maintain a global job id 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