https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=perf-tmp 2020-07-28T00:51:13+00:00 2020-07-28T00:51:13+00:00 mark markm@cs.wisc.edu 2020-06-12T02:31:49+00:00 urn:sha1:2c31b45ae878b821975c4ebd94cc1e49f6073fd0 2020-03-09T16:23:23+00:00 Dan Aloni dan@kernelim.com 2020-03-09T15:40:31+00:00 urn:sha1:0605abe3bb7b602cbe70a72797fdd6ca90d76e92 2019-12-22T22:42:47+00:00 Mark Rousskov mark.simulacrum@gmail.com 2019-12-22T22:42:04+00:00 urn:sha1:a06baa56b95674fc626b3c3fd680d6a65357fe60 2019-10-22T17:23:10+00:00 Mateusz Mikuła matti@marinelayer.io 2019-09-05T11:30:30+00:00 urn:sha1:95c06a29707c8b2f811495c05b0cd009743e29de 2019-04-04T14:19:14+00:00 Alex Crichton alex@alexcrichton.com 2019-04-03T19:18:38+00:00 urn:sha1:cb57484dcaeb4881c73f8a1174d4d5661ca2bbe2 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 2019-03-31T10:56:51+00:00 Mazdak Farrokhzad twingoow@gmail.com 2019-03-01T08:34:11+00:00 urn:sha1:379c380a60e7b3adb6c6f595222cbfa2d9160a20 2019-03-22T22:56:40+00:00 Linus Färnstrand faern@faern.net 2019-03-22T21:14:35+00:00 urn:sha1:1ccad16231f58b09f127e679d54162acbc2f0dae 2019-02-27T19:06:15+00:00 Taiki Endo te316e89@gmail.com 2019-02-10T19:23:21+00:00 urn:sha1:93b6d9e086c6910118a57e4332c9448ab550931f 2019-01-24T04:36:38+00:00 Alex Berghage bearcage@ludumipsum.com 2019-01-24T04:36:38+00:00 urn:sha1:14ce5364de3bf7d2da59fbe52360459c0f2c6ada 2019-01-23T02:31:55+00:00 Alex Berghage bearcage@ludumipsum.com 2019-01-23T02:31:55+00:00 urn:sha1:41be93c2f694b6b8c493b255d2e77c0703135b14