When using the new custom default executors, sometimes we end up
taking a long time to do a task switch. This is happening because
the path the new code takes sometimes results in a concrete pointer
to the default global executor being in the executor tracking
information in `swift_task_switch()`, and if we try to switch to
a `nil` task executor (which _also_ means the default global executor),
we aren’t spotting that and we’re taking the slow path.
Essentially, we want to take the fast path in cases where we switch
from `nil` to the concrete default global executor and vice-versa.
rdar://156701386
`ExecutorImpl.cpp` should be moved from `SWIFT_RUNTIME_CONCURRENCY_NONEMBEDDED_C_SOURCES` to `SWIFT_RUNTIME_CONCURRENCY_C_SOURCES`. This way we can also include `ExecutorImpl.swift` and use `PlatformExecutorCooperative.swift` in embedded concurrency for WASI.
In task-to-thread concurrency mode, `_getMainExecutorAsSerialExecutor`
returns `SerialExecutorRef::generic()`, which is, give or take, NULL.
Unfortunately we'd declared it as returning `any SerialExecutor`,
rather than `(any SerialExecutor)?`, and then the `getMainExecutor()`
function was calling `asUnownedSerialExecutor()` on it, which then
crashes.
rdar://153152063
If you use SwiftStdlibCurrentOS availability, you will be able to
use new types and functions from within the implementation. This
works by, when appropriate, building with the CurrentOS availability
set to the current deployment target.
rdar://150944675
We were failing to switch executors to Dispatch queues, where those
were being used as executors, which caused a variety of unusual
symptoms.
rdar://150310927
This changes the isIsolatingCurrentContext function to return `Bool?`
and removes all the witness table trickery we did previously to detect
if it was implemented or not. This comes at a cost of trying to invoke
it always, before `checkIsolated`, but it makes for an simpler
implementation and more checkable even by third party Swift code which
may want to ask this question.
Along with the `withSerialExecutor` function, this now enables us to
check the isolation at runtime when we have an `any Actor` e.g. from
`#isolation`.
Updates SE-0471 according to
https://forums.swift.org/t/se-0471-improved-custom-serialexecutor-isolation-checking-for-concurrency-runtime/78834/
review discussions
I had originally thought that we'd get away without this because the
executor construction generally happens in the async `main` function,
but of course if a program doesn't already use Swift Concurrency,
and someone uses it from a plug-in or library it loads, there's a
risk that we might have a race condition.
rdar://149346132
Rename `DispatchTaskExecutor` to `DispatchGlobalTaskExecutor` as we
may want to use the former for an executor that runs things on an
arbitrary Dispatch queue.
Rename `DispatchExecutor` to `DispatchExecutorProtocol`; again, we
might want the name for something else.
Add `@Sendable` attribute to `registerEvent`.
Fix missing `extern "C" SWIFT_CC(swift)` on `_swift_exit` (merge
error).
Remove stray whitespace from `CMakeLists.txt`
rdar://141348916
We can't use blocks, because Swift doesn't support them on Linux or
Windows. Instead, use a C function pointer, and box up the handler.
rdar://141348916
Added an `-executor-factory` argument to the compiler to let you safely
specify the executors you wish to use (by naming a type that returns
them).
Also added some tests of the new functionality.
rdar://141348916
Reorganise the Concurrency code so that it's possible to completely
implement executors (both main and global) in Swift.
Provide API to choose the desired executors for your application.
Also make `Task.Sleep` wait using the current executor, not the global
executor, and expose APIs on `Clock` to allow for conversion between
time bases.
rdar://141348916
