This only modifies the runtime function `swift_task_enqueueGlobalWithDeadline` to take new clock primitive to
interoperate with existing dispatch wall clock values.
The Concurrency runtime calculates deadlines for scheduling itself
using `swift_get_time()`; unfortunately, on Windows that was using
`QueryPerformanceCounter()`, while Dispatch uses
`QueryInterruptTimePrecise()`. The problem with that is that the two do
not necessarily correspond *at all*. In general
`QueryPerformanceCounter()` may be using any of a number of hardware
timers depending on the machine on which we're running.
In the VM I was testing on, the two differed by 20ms, but the worst case
is that they are completely unrelated, in which case `Task.sleep()` will
wait essentially a random amount of time.
rdar://135413803
WASI doesn't have "suspending-time" concept, so use `CLOCK_MONOTONIC`
for both "continuous" and "suspending" clocks. WASI's "monotonic"
doesn't guarantee any underlying system call implementation, but most
of major implementations use `CLOCK_MONOTONIC` for all underlying
platforms.
This partially buildfixes this platform.
See also: https://github.com/WebAssembly/WASI/blob/main/phases/snapshot/docs.md#variant-cases
* Ensure clocks properly respect leeways and use raw time for calculations for continuous clocks
* slurp up time calcualtions to inline forms
* ensure the tolerance codepaths get tested as well
* Use task local storage for task sources in leeway based calculations
* use comparison assertions for leeway based calculations
* Whitespace cleanup
* Use the CLOCK_MONOTONIC value for linux to be compatible with linux scheduling for dispatch
* remove incorrect paren in macro check for OpenBSD
* Address feedback and remove stray ;
Reading SE-0329 and this module, two clock types are broadly defined,
"continuous", which advances during suspension, and "suspending", which
does not.
SE-0329 notes the behavior of the clock types on "Darwin and BSD" is
that `CLOCK_MONOTONIC` is "continuous" and `CLOCK_UPTIME` is
"suspending". This is also true for OpenBSD (see
https://man.openbsd.org/clock_gettime).
Update code to match. This buildfixes this platform.
These used to set the clock id incorrectly, leading to zero results. Fix that and also make the underlying entry point abort if it gets an invalid ID, preventing this from reoccurring.
* [WIP] Initial draft at v2 Clock/Instant/Duration
* Ensure the literal types for _DoubleWide are able to be at least 64 bits on 32 bit platforms
* static cast timespec members to long
* Remove runtime exports from clock functions
* Export clock functions in implementations as they are in headers
* Clean up internal properties by adding leading underscores, refine availability to a TBD marker macro, and break at 80 lines to match style
* Shift operators to concrete Instant types to avoid complexity in solver resolution
* Adjust diagnostic note and error expectation of ambiguities to reflect new potential solver (perhaps incorrect) solutions
* Update stdlib/public/Concurrency/TaskSleep.swift
Co-authored-by: Karoy Lorentey <klorentey@apple.com>
* [stdlib][NFC] Remove trailing whitespace
* [stdlib] Remove _DoubleWidth from stdlib's ABI
* [stdlib] Strip downd _DoubleWidth to _[U]Int128
* Additional adjustments to diagnostic notes and errors expectation of ambiguities to reflect new potential solver (perhaps incorrect) solutions
* Disable type checker performance validation for operator overload inferences (rdar://33958047)
* Decorate Duration, DurationProtocol, Instant and clocks with @available(SwiftStdlib 9999, *)
* Restore diagnostic ambiguity test assertion (due to availability)
* Add a rough attempt at implementing time accessors on win32
* Remove unused clock id, rename SPI for swift clock ids and correct a few more missing availabilities
* remove obsolete case of realtime clock for dispatch after callout
* Use the default implementation of ~ for Int128 and UInt128
* Ensure diagnostic ambiguitiy applies evenly to all platforms and their resolved types
* Restore the simd vector build modifications (merge damage)
* Update to latest naming results for Instant.Duration
* Updates to latest proposal initializers and accessors and adjust encoding/decoding to string based serialization
* Update availability for Clock/Instant/Duration methods and types to be 5.7
* Correct *Clock.now to report via the correct runtime API
* Ensure the hashing of Duration is based upon the attoseconds hashing
* Avoid string based encoding and resort back to high and low bit encoding/decoding but as unkeyed
* Adjust naming of component initializer to use suffixes on parameters
* Duration decoding should use a mutable container for decoding
* fix up components initializer and decode access
* Add platform base initializers for timespec and tiemval to and from Duration
* Add some first draft documentation for standard library types Duration, DurationProtocol and InstantProtocol
* Another round of documentation prose and some drive-by availability fixes
* InstantProtocol availability should be 5.7
* Correct linux timeval creation to be Int and not Int32
Co-authored-by: Karoy Lorentey <klorentey@apple.com>
