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
* [Concurrency] Initial steps for startSynchronously for Task
* [Concurrency] Rename to _startSynchronously while in development
* [Concurrency] StartSynchronously special executor to avoid switching
* startSynchronously bring back more info output
* [Concurrency] startSynchronously with more custom executor tests
* add missing ABI additions to test for x86
* [Concurrency] gyb generate _startSynchronously
* [Concurrency] %import dispatch for Linux startSynchronously test
* [Concurrency] Add TaskGroup.startTaskSynchronously funcs
* [Concurrency] DispatchSerialQueue does not exist on linux still
Previously these records were not used at all, so changing this has no
impact on existing runtimes. Note that we changedd the FunctionType
because the previous one was slightly incorrect -- the context comes
LAST in the type, not first.
We should build a 64-bit value from the two 32-bit Id fields, but we were shifting one field by the other. Coincidentally, this managed to produce the correct value until the ID goes beyond 2^32, but after that it's weird and wrong.
Replace NextLinkType with Item::Kind with more clear definition.
Use llvm::PointerIntPair<>.
Use hierarchy of classes instead of optional fields inside Item.
Combined Storage::copyToOnlyOnlyFromCurrentGroup() into Storage::initializeLinkParent().
Also create parent task marker when copying items created inside withTaskGroup().
Removed Storage::peekHeadLinkType().
In embedded mode, we mustn't have references to the C++ library, because
some embedded platforms don't include the C++ library.
Additionally, it's good to avoid use of global operator new and operator
delete, because they can be globally overridden and this has bitten us
in the past.
rdar://137286187
We have been only including a subset of files and functionality on Embedded Concurrency, let's instead include all the
source files, and have a fine grained opt out on things that don't yet work. Namely, this is still avoiding clocks, task
sleeping and custom executors.
Add a test for AsyncStream and continuations on Embedded Concurrency.
The way that we include COMPATIBILITY_OVERRIDE_INCLUDE_PATH freaks out the
syntax highlighting of editors like emacs. It causes the whole file to be
highlighted like it is part of the include string.
To work around this, this patch creates a separate file called
CompatibilityOverrideIncludePath.h that just includes
COMPATIBILITY_OVERRIDE_INCLUDE_PATH. So its syntax highlighting is borked, but
at least in the actual files that contain real code, the syntax highlighting is
restored.
`ExecutorHooks.h` is now nothing to do with hooks, so rename it. Also
there are some additional functions it should declare, and a couple of
places where we've slightly messed up the boundary, for instance
`swift_task_asyncMainDrainQueue` was defined in `Task.cpp` rather than
in the executor implementations, which is wrong, so fix that too.
`CooperativeGlobalExecutor.cpp` now builds against the interface from
`ExecutorImpl.h`, rather than including the all the concurrency headers.
rdar://135380149
C++ executor implementations were `#include`ed into `GlobalExecutor.cpp`,
which makes it difficult to replace the global executor when using the
Embedded Concurrency library. Refactor things so that they build into
separate objects, which means replacing them is just a matter of writing
the relevant functions yourself.
rdar://135380149
SWIFT_DEBUG_VALIDATE_UNCHECKED_CONTINUATIONS works by tracking the context pointers of active continuations, and verifying that a resumed context is in the set of active continuations. However, the resume calls are passed the task pointer, not the context pointer. The context pointer is recovered from the task. If the task has been destroyed, the context pointer is invalid. This can result in a weird error message or it can crash if the context pointer is used before checking it against the active continuations.
Instead, track tasks that are suspended pending an unchecked continuation. If the task is destroyed, we'll still be passed the dangling pointer and check that pointer against the tracking info. We must be sure to check that before trying to use anything inside it.
rdar://131858544
* [Concurrency] Fix task excutor handling of default actor isolation
The task executor API did not properly account for taking the default
actor locking into account when running code on it, we just took the job
and ran it without checking with the serial executor at all, which
resulted in potential concurrent executions inside the actor --
violating actor isolation.
Here we change the TaskExecutor enqueue API to accept the "target"
serial executor, which in practice will be either generic or a specific
default actor, and coordinate with it when we perform a
runSynchronously.
The SE proposal needs to be amended to showcase this new API, however
without this change we are introducing races so we must do this before
the API is stable.
* Remove _swift_task_enqueueOnTaskExecutor as we don't use it anymore
* no need for the new protocol requirement
* remove the enqueue(_ job: UnownedJob, isolatedTo unownedSerialExecutor: UnownedSerialExecutor)
Thankfully we dont need it after all
* Don't add swift_defaultActor_enqueue_withTaskExecutor and centralize the task executor getting to enqueue()
* move around extern definitions
condvar before we try to tail-call. This is necessary because the
swiftasync tail-call handling is (reasonably) reluctant to reorder
cleanups so that locals are destroyed before the call, and of course it
cannot destroy them after it and still emit a tail call.
Old versions of clang handled these tailcalls differently and failed
to diagnose this, but I'm pretty sure they just ended up not doing a
tail call rather than actually doing anything reasonable.
Fixes rdar://125363169
When using a future adapter, the resume context may not be valid after the task starts running. Only peer through the adapter when we're starting to run.
rdar://126298035
This has been the behavior of the runtime since the initial release.
Initially, it was thought that task executors would provide similar
functionality, so they naturally took over the enumerator. After that
changed, we forgot to change it back. Fortunately, we haven't released
any versions of Swift with the task executors feature yet, so it's not
too late to fix this.
The function is marked `noreturn` but the compiler was not able to reason
statically about whether this constraint is met. From code inspection it's
clear that the call to `swift_task_donateThreadToGlobalExecutorUntil()` does
not return, so `swift_unreachable()` can be used to suppress the warning.
Since https://github.com/apple/swift/pull/65613, DiscardingTG started to
accept `() -> Void` instead of `() -> T`, but it also changed the number
of arguments accepted by the closure from 3 to 2. So it should use
`non_future_adapter` instead of `future_adapter` to avoid runtime signature
mismatch.
