This addresses an unintended instance where new dispatch functionality
is not used on Windows as the lookup was never performed. This limits
the runtime to shared linking which should generally be a safe
assumption on Windows.
We were detaching the child by just modifying the list, but the cancellation path was assuming that that would not be done without holding the task status lock.
This patch just fixes the current runtime; the back-deployment side is complicated.
Fixes rdar://88398824
Under the task-to-thread model, specifying a priority doesn't make
sense.
Here, variations of addTask and addTaskUnlessCancelled are introduced
which do not take a priority. Additionally, the original functions are
made unavailable.
Load task status with an acquire when canceling a task, to synchronize with the store-release that comes when updating a task's status.
Add explicit TSan calls in cancellation, as well as withStatusRecordLock and addStatusRecord, to avoid TSan complaining about data races when canceling a task.
Add a test that checks for TSan-reported data races when canceling a task.
rdar://93892417
This replaces a number of `#include`-s like this:
```
#include "../../../stdlib/public/SwiftShims/Visibility.h"
```
with this:
```
#include "swift/shims/Visibility.h"
```
This is needed to allow SwiftCompilerSources to use C++ headers which include SwiftShims headers. Currently trying to do that results in errors:
```
swift/swift/include/swift/Demangling/../../../stdlib/public/SwiftShims/module.modulemap:1:8: error: redefinition of module 'SwiftShims'
module SwiftShims {
^
Builds.noindex/swift/swift/bootstrapping0/lib/swift/shims/module.modulemap:1:8: note: previously defined here
module SwiftShims {
^
```
This happens because the headers in both the source dir and the build dir refer to SwiftShims headers by relative path, and both the source root and the build root contain SwiftShims headers (which are equivalent, but since they are located in different dirs, Clang treats them as different modules).
In the task-to-thread model, there are no threading mechanisms by which
work could be offloaded onto another thread. As such, callback based
asynchronous APIs which are not Swift async do not make sense.
rdar://99047747
The continuation types were conditionally `Sendable` based on whether
the result type of the continuation was `Sendable`. However,
conceptually, the return value is never leaving the current task, so
it is never actually crossing concurrency boundaries. Therefore, we
can make the continuation types unconditionally `Sendable`.
Fixes rdar://98462858.
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
