It cannot be used for executing general-purpose work, because such function would need to have a different signature to pass isolated actor instance.
And being explicit about using this method only for deinit allows to use object pointer for comparison with executor identity.
* [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
This reverts c07aa9c425 which was done to
avoid a crash in optimnized caused by this PR:
https://github.com/apple/swift/pull/41088
Since this was almost 2 years ago, we probably don't have this issue
anymore as far as I can see other resolved issues, so try to remove the
workaround.
Resolves rdar://88711954
can be reentrantly executed.
I don't think doing this is *actually a good idea*, but corrupting the
runtime is an even worse idea, and the overhead here is very low.
ASL is deprecated in macOS 10.12. It may be time to transition to os_log now
that deployment targets have been raised to 10.12, but until that project
starts these warnings are just pollution.
Filed rdar://121066531 to track adoption of `os_log()` if appropriate.
which executor for which type of setting, is consolidated and we have a
single knob we use to determine when to use dispatch as our global
executor.
Radar-Id: rdar://problem/119416196
Once we have transitioned the actor into a new state, we report the
state change as a trace event so it can be noted by tools (e.g.,
Instruments). However, the act of transitioning to a new state can mean
that there is an opportunity for another thread to deallocate the
actor. This means that the tracing call cannot depend on dereferencing
the actor pointer.
A refactoring a few months ago to move the bit that indicates when a
distributed actor is remote from inside the atomic actor state out to a
separate field (because it's constant for a given actor instance),
which introduced a dereference of the actor instance in forming the
tracing call. This introduced a narrow window in which a race
condition could occur: the actor transitions to an idle state, and is
then deallocate before the trace event for the actor transition occurs,
leading to a use-after-free.
Fetch this bit of information earlier in the process, before any state
changes and when we know the actor is still allocated, and pass it
through to the tracing code.
Fixes rdar://108497870.
* [Executors][Distributed] custom executors for distributed actor
* harden ordering guarantees of synthesised fields
* the issue was that a non-default actor must implement the is remote check differently
* NonDefaultDistributedActor to complete support and remote flag handling
* invoke nonDefaultDistributedActorInitialize when necessary in SILGen
* refactor inline assertion into method
* cleanup
* [Executors][Distributed] Update module version for NonDefaultDistributedActor
* Minor docs cleanup
* we solved those fixme's
* add mangling test for non-def-dist-actor
is only needed for acknowledging asynchronous overrides from other
threads, onto the thread itself. It is not needed for self-overrides.
Radar-Id: rdar://problem/101864092
lock() and release on unlock() and use consume when are relying on
address dependency HW load ordering. Adjust tsan annotations to match.
Radar-Id: rdar://problem/101864092
it is enqueued on. This way, we have the necessary bookkeeping to
escalate an executor when a task that is enqueued, is escalated.
Radar-Id: rdar://problem/101864092
