The new intrinsic, exposed via static functions on Task<T, Never> and
Task<T, Error> (rethrowing), begins an asynchronous context within a
synchronous caller's context. This is only available for use under the
task-to-thread concurrency model, and even then only under SPI.
Previously getAsyncClosureEntryPointAndContextSize took both a pointer
for a function and a closure context. That was a relic of a temporary
ABI where async function pointers were not used in all cases. Now that
that ABI is long gone, async function pointers are always used.
Consequently, the closure context argument was unused. Here, the
closure context argument is removed.
The Windows path uses `LoadLibrary` which should use `Windows.h` for the
declaration as per MSDN. This avoids an unnecessary warning when
building for Windows.
As soon as the waiting task is successfully enqueued on the blocking
task, both tasks have to be considered invalidated because the
blocking task can concurrently complete and resume its waiters:
- The waiting task ensures that the blocking task is valid while
it's waiting. However, that's measured from the perspective of
the waiting task, not from the perspective of the thread that was
previously executing it. As soon as the waiting task is resumed,
the wait call completes and the validity guarantee on the blocking
task disappears, so the blocking task must be treated as
invalidated.
- The waiting task ensures that it is valid as long as it isn't
complete. Since it's trying to wait, it must not be complete.
However, as soon we resume it, it can complete, so the waiting
task must also be treated as invalidated.
This is one of those things that's not really easy to test, and the
need for a fix is pretty urgent, so I'm submitting this patch without
a test. I'll try to land a race test that demonstrates the bug in
the next few days.
@kavon deserves all the credit here for some truly heroic debugging
and finally recognizing the flaw in the code; I'm just popping in
at the last minute to sheepishly patch the bug.
Fixes rdar://92666987
`SWIFT_BUILD_STATIC_STDLIB` is not mutually exclusive with
`SWIFT_BUILD_DYNAMIC_STDLIB`, and Linux sets both, so we can't use
`SWIFT_BUILD_STATIC_STDLIB` to conditionalise things.
The linker error about duplicate definitions for the threading error
handler was happening because we were forced to include the object
containing that symbol; moving it to another object should fix that.
And it turns out there's a way to get CMake to include the threading
object library only when building a shared object, so use that too.
rdar://90776105
When we're building static libraries, we don't need to include the
threading objects in both Concurrency and Core, and we also don't need
two copies of the threading library's fatal error handler.
rdar://90776105
There's no guarantee that e.g. pthread_key_t is an integral type. It could
be some kind of struct, or some other thing that isn't valid as a template
argument.
rdar://90776105
We shouldn't include <windows.h> implicitly from .cpp files, but should
do it directly so that we know it's there.
Also, if we're including <windows.h>, do it at the top of the file.
rdar://90776105
Moved all the threading code to one place. Added explicit support for
Darwin, Linux, Pthreads, C11 threads and Win32 threads, including new
implementations of Once for Linux, Pthreads, C11 and Win32.
rdar://90776105
SWIFT_STDLIB_SINGLE_THREADED_RUNTIME is too much of a blunt instrument here.
It covers both the Concurrency runtime and the rest of the runtime, but we'd
like to be able to have e.g. a single-threaded Concurrency runtime while
the rest of the runtime is still thread safe (for instance).
So: rename it to SWIFT_STDLIB_SINGLE_THREADED_CONCURRENCY and make it just
control the Concurrency runtime, then add a SWIFT_STDLIB_THREADING_PACKAGE
setting at the CMake/build-script level, which defines
SWIFT_STDLIB_THREADING_xxx where xxx depends on the chosen threading package.
This is especially useful on systems where there may be a choice of threading
package that you could use.
rdar://90776105
- Revise '// Prints' comments style like the other stdlib files
- Remove verbose string interpolations and extra spaces
- Remove some unneeded parentheses
- Replace the majority of ' : ' with ': '
- Fix wrong indentation
- Keep files with a single empty line at the end
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 ;
Change continuation signposts to emit an interval for init/resume.
Fix task_create to take the decoded flags as separate parameters, matching other calls.
Move job_run trace calls into runJobInEstablishedExecutorContext. swift_job_runImpl didn't catch everything.
rdar://92149411
