We need the `init?(JobPriority)` constructor to be
`StdlibDeploymentTarget 5.9`
so the compiler will not complain when we reference it
from `ExecutorJob.createTrampoline` when building the standard library
without strict availability.
Addresses rdar://159397287
We were terminating after the first set of jobs; if one of them scheduled
another job, and there were no timers running, we would terminate,
which was wrong.
If a job enqueues another job on the executor, we might never leave
the inner `while` loop in the `run()` method. Fix this by taking
the contents of the run queue and only running those jobs in the
queue at the time we enter the inner loop.
I don't think we actually need this. If you have a non-canonical
(i.e. derived) clock, you can just implement `enqueue` and/or `run`
and call those methods on the clock you're wrapping.
We no longer attempt to convert timestamps from the passed-in `Clock`
in order to allow any clock to work with any executor. Instead,
executors that do not recognise a clock should call the `enqueue`
function on that `Clock`, which lets the `Clock` itself decide how
to proceed.
Additionally, rename `SchedulableExecutor` to `SchedulingExecutor`.
Previously, we skipped checking the return type of a function for safety
as we expected to warn at the use of the returned value:
let x = returnsUnsafe()
usesUnsafe(x) // warn here
Unfortunately, this resulted in missing some unsafe constructs that can
introduce memory safety issues when the use of the return value had a
different shape resulting in false negatives for cases like:
return returnsUnsafe()
or
usesUnsafe(returnsUnsafe())
This PR changes the analysis to always take return types of function
calls into account.
rdar://157237301
a550080 added a call to the new initializer, but that call
came from a function annotated with `StdlibDeploymentTarget 6.2`,
rather than `SwiftStdlib 6.2`, while the initializer was set to
`SwiftStdlib 6.2`. This will fail in some build configurations
(specifically where the target being built for is older than that
implied by `SwiftStdlib 6.2`).
rdar://157217460
The test was crashing due to `swift_unreachable("custom executors not supported in embedded Swift")` line in `swift_task_enqueueImpl`, as the corresponding non-embedded codepath was relying on an unspecialized generic function `_swift_task_enqueueOnExecutor` defined in `Executor.swift`. Unspecialized generics are unavailable in Embedded Swift, and such `@silgen_name` function can't be specialized when used from concurrency runtime code written in C/C++. We can redefine this function for Embedded Swift as using a class-bound existential instead, and re-enable this codepath with a slightly different call that avoids the use of unavailable `swift_getObjectType` function from the non-embedded runtime.
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
Concurrency from the Core project is importing the Darwin platform
overlay, which in turn depends on SwiftCore from the Core project,
breaking the project layering.
Concurrency only needs the Clang module, but Swift does not have a
mechanism to only import a clang module. For now import the
functionality needed from Darwin by importing and wrapping the
associated functions from `<dlfcn.h>` within `CFExecutor.cpp`
Also remove Darwin import from `AsyncStreamBuffer.swift` because it is
not used
`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.
Most of linkers pull object files from static archives only if any
symbol from that object file is referenced, even if the object contains
a ctor code. `Setup.cpp` didn't have any symbols referenced from
other code, so it was not linked in when the concurrency runtime was
linked in statically. This commit moves the ctor code to `Task.cpp`
to ensure that it is always linked in.
This function is used by the executor to help schedule the async job.
While not currently available on Windows on main, this allows correctly
handling the presence of the symbol for static linking.
In preparation for removal. This spelling of Task.immediate was before
SE-review and was NOT accepted and therefore we should try to remove it
entirely.
Although we would like these to be dynamic, we currently cannot build
them properly due to limitations of the build system. Adjust the build
to pass in additional flags to properly build the runtimes for that
environment as a temporary measure.
- Move the definition of 'structured concurrency' to the beginning of
the section.
- Avoid future tense. Fix some mixed future+present tense errors.
- Write bullet points as individual sentences, not as the clauses of one
long sentence.
- Apple Style: Use 'since' only in the sense of 'after'.
- Apple Style: Use 'you' instead of 'one'.
- Apple Style: Close up 'non-' except when ambiguous.
- DevPubs style: Avoid bare 'this' for clarity. Here, 'this guarantee'
tells the reader what 'this' refers to.
- DevPubs style: Avoid 'may' which can be ambiguous between possibility
and permission.
Task-to-thread model doesn't have `ExecutorJob`, so we can't use it;
however, we probably also don't need `_swift_createJobForTestingOnly`
there so just `#if` it out in that case.
rdar://155054460
