diff options
| author | bors <bors@rust-lang.org> | 2019-04-04 18:22:34 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2019-04-04 18:22:34 +0000 |
| commit | 53f2165c544cceeafb308b80ace656ed328c1dc2 (patch) | |
| tree | 466cac9ab52e35a9b5e95beafb5b5f4858dde57c /src/libstd/sys/unix/stack_overflow.rs | |
| parent | 52980d0fb39134a26f73b39b384407e010fc3af5 (diff) | |
| parent | cb57484dcaeb4881c73f8a1174d4d5661ca2bbe2 (diff) | |
| download | rust-53f2165c544cceeafb308b80ace656ed328c1dc2.tar.gz rust-53f2165c544cceeafb308b80ace656ed328c1dc2.zip | |
Auto merge of #59676 - alexcrichton:osx-deadlock, r=sfackler
std: Avoid usage of `Once` in `Instant` This commit removes usage of `Once` from the internal implementation of time utilities on OSX and Windows. It turns out that we accidentally hit a deadlock today (#59020) via events that look like: * A thread invokes `park_timeout` * Internally, only on OSX, `park_timeout` calls `Instant::elapsed` * Inside of `Instant::elapsed` on OSX we enter a `Once` to initialize global timer data * Inside of `Once`, it attempts to `park` This means on the same stack frame, when there's contention, we're calling `park` from inside `park_timeout`, causing a deadlock! The solution implemented in this commit was to remove usage of `Once` and instead just do a small dance with atomics. There's no real need we need to guarantee that the global information is only learned once, only that it's only *stored* once. This implementation may have multiple threads invoke `mach_timebase_info`, but only one will store the global information which will amortize the cost for all other threads. A similar fix has been applied to windows to be uniform across our implementations, but looking at the code on Windows no deadlock was possible. This is purely just a consistency update for Windows and in theory a slightly leaner implementation. Closes #59020
Diffstat (limited to 'src/libstd/sys/unix/stack_overflow.rs')
0 files changed, 0 insertions, 0 deletions
