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
Previously there was still a sneaky hop which caused ordering issues.
This introduced a specific test startSynchronously_order which checks
that the task enqueues indeed are "immediate" and cleans up how we
handle this.
This also prepares for the being discussed in SE review direction of
this API that it SHOULD be ALLOWED to actually hop and NOT be
synchronous at all IF the isolation is specified on the closure and is
DIFFERENT than the callers dynamic isolation.
This effectively implements "synchronously run right now if dynamically
on the exact isolation as requested by the closure; otherwise enqueue
the task as usual".
resolves rdar://149284186
cc @drexin
Tweaked diagnostic to use a string instead of a type. Renamed the
feature in `FeatureAvailability.def` (and added the `TaskExecutor`
feature to 6.2). Also fixed the `swift_getActiveExecutor()`
function to return the main executor only when on the main thread.
rdar://141348916
* [Concurrency] Detect non-default impls of isIsolatingCurrentContext
* [Concurrency] No need for trailing info about isIsolating... in conformance
* Apply changes from review
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
This entrypoint is similar to swift_task_isCurrentExecutor except that it
provides an ABI level option flag that enables one to configure its behavior in
a backwards deployable manner via the option flag.
I used this to expose at the ABI level the ability to check the current executor
without crashing on failure, while preserving the current behavior of
swift_task_isCurrentExecutor (which crashes on failure).
I am going to use this to implement swift_task_runOnMainActor.
It's possible that the job we enqueue holds the last strong reference to the actor. If that job runs on another thread after we enqueue it, then it's possible for `this` to be destroyed while we're still in this function. We need to use `this` after the enqueue when the priorities don't match. When it looks like that will happen, retain `this` before the enqueue to ensure it stays alive until we're done with it.
Introduce a defensive retain helper class that makes it easy to do a single retain under certain conditions even in a loop, and does RAII to balance it with a release when the scope exits.
rdar://135400933
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
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.
We were missing a field in `SwiftJob`, which broke various things. To
avoid that problem in future, this PR adds a set of static asserts to
check the layout of various structures and that we're using the same
values as well.
Also added some functions to the ABI, and fixed things so that if you
enable the debug logging the library still builds (there was an extra
`_` in `Actor.cpp` that caused a build failure).
Finally, renamed `Hooks.cpp` to `ConcurrencyHooks.cpp`.
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
After we've enqueued a job, another thread may run it and destroy it. Don't try to get the job's task executor preference when we try to schedule it. Instead, get the task executor preference before enqueueing the job, then use that preference when scheduling if necessary. Since getting the executor preference is potentially somewhat expensive (we need to search the status records for an executor preference record), only do this if the pre-compare-and-swap states look like they'll need it.
rdar://136281920
The executor may execute and free the task while the enqueue code is still finishing up. If that code tries to get an async backtrace (for example, if it calls malloc/free with malloc stack logging enabled) then it will find a dangling pointer in the current task TSD, and dereferencing it may crash.
rdar://130125017
