| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Late-breaking design change: all events should be declared with nullable delegate types.
|
|
* Remove !s and TODO-NULLABLE comments for [DoesNotReturn]
* Remove !s and TODO-NULLABLE comments for [NotNullIfNotNull]
* Remove !s and TODO-NULLABLE comments for writes via Interlocked.CompareExchange
* Remove !s and TODO-NULLABLE comments for Debug.Assert on fields
* Update/add several TODO-NULLABLE comments
|
|
If the debugger evaluates a `ValueTask<T>`'s `Result`, that counts as the "you should only consume a `ValueTask<T>`" once, and ends up breaking / hanging / throwing exceptions and other bad stuff while stepping through code in the debugger.
This commit addresses that in two ways:
1. Adds `[DebuggerBrowsable(Never)]` to `Result` to prevent it from showing up in debugger views.
2. Adds a NotifyOfCrossThreadDependency call to its ToString. This prevents the debugger from using ToString to show an implicit representation of the instance, and it forces the developer explicitly trying to access ToString (e.g. in the watch window) to click a button acknowleding the impact.
(Post 3.0, we should consider removing the `ValueTask<T>.ToString()` override altogether.)
|
|
Also update TODO-NULLABLE comments to be more specific where appropriate.
|
|
|
|
|
|
* Force secondary await continuations to run asynchronously
For performance reasons, await continuations have been invoked synchronously, meaning they're invoked as part of the antecedent task's completion (as long as that task allows it, as long as there's sufficient stack space, etc.) This generally works out well in the case where there's a single await continuation, which is far and away the common case. However, it can cause problems in situations where there are multiple await continuations, as those continuations will end up being serialized, which can lead to slowdowns and deadlocks in niche situations. To address that, this commit backs off a bit. The first await continuation is still invoked synchronously, but subsequent await continuations are invoked asynchronously, such that they are not blocked by a previously registered await continuation.
* Fix nits
|
|
|
|
|
|
Fix some nullable annotations from API Review
|
|
|
|
|
|
|
|
It's just StrongBox<T>.
|
|
* Add and apply nullable attributes
* Adapt to API review decisions
* Address PR feedback
|
|
respectively (master) (#24369)
* Update BuildTools, CoreClr to preview4-04022-01, preview6-27721-71, respectively
* Use `Nullable=enable` rather than `NullableContextOptions=enable`
* Resolving new nullability warnings
* PR Feedback
|
|
* Enable nullable at the project level
* Remove `#nullable enable` from individual files
Removes `#nullable enable` from almost all .cs files in System.Private.CoreLib. I left it only in the ~30 files (out of ~1480 that had it) that are mirrored to corefx, that are built into projects by corefx that don't yet set NullableContextOptions at the project level, and that use nullable annotations; otherwise, they'd break the corefx build.
|
|
Convert managed product binary to use SDK project system.
- Uses Arcade for versions strings
- Overrides Arcade defined output paths - should change in the future
|
|
(#24331)
We decided after all to put these on a different type, TaskAsyncEnumerableExtensions. This commit adds the new type. We can delete the methods in the old location once corefx consumes an updated build and switches over to using the new ones.
|
|
|
|
|
|
* Nullable: System.Threading.Tasks
* Address PR feedback
|
|
Signed-off-by: dotnet-bot <dotnet-bot@microsoft.com>
|
|
Currently Task has a stack depth check that avoids stack overflows on very deep stack continuation chains, but it only applies to Task.ContinueWith, not to other kinds of continuations. This changes that to have it apply to all.
As part of this, this also deletes the current StackGuard type used to achieve the check. The type was meant to avoid expensive calls to check where we are on the stack, but now that we're using TryEnsureSufficientExecutionStack, it's actually faster to just call that rather than access the current StackGuard from a ThreadLocal. This then also cleans up the call sites nicely, as they no longer need finally blocks to undo the increment performed on the StackGuard.
|
|
Signed-off-by: dotnet-bot <dotnet-bot@microsoft.com>
|
|
* Move Thread to shared CoreLib
* Remove all local variables from Thread in shared code
* Remove duplicate checks
* Port back CoreRT changes needed for shared code
* Fix missing culture initialization in ThreadStart()
* Adjust for shared WaitHandle
|
|
* Reduce struct copy by 1 in ValueTask.GetAwaiter
* Bit more explicit
|
|
Just move the helper being used to ThrowHelper.
|
|
|
|
* Fix race condition in ManualResetValueTaskSourceCore
ManualResetValueTaskSourceCore.GetStatus is used from ValueTaskAwaiter.IsCompleted. If GetStatus returns Success too early, then IsCompleted will also return true too early, which will result in GetResult being called too early. This doesn't happen today when an MRVTSC is used sequentially. But if an instance is pooled by the object its stored on getting put back into a pool as part of a call to the wrapper's GetResult, then we can end up in the following situation:
- Thread 1 starts an await on an instance containing an MRVTSC. It calls IsCompleted.
- Thread 2 starts to complete that instance, getting as far as calling SignalCompletion and setting _completed to true but not yet setting _continuation.
- Thread 1 sees _completed == true and returns true from IsCompleted. It calls GetResult, and the wrapper extracts the result from the instance, resets it, and puts it back into the pool.
- Thread 3 takes the object out of the pool and starts using it.
- Thread 2 continues SignalCompletion on that instance, and sets _continuation to the sentinel.
- Now Thread 3's instance's _continuation is the sentinel when it should be null. If it calls SignalCompletion, it'll erroneously find that _continuation is not null and will queue _continuation/_continuationState for execution, resulting in the sentinel getting executed. If it calls OnCompleted, it'll find that the _continuation is not null, and will queue the supplied continuation/state to execute immediately even though the operation may not yet actually be done.
The fix is simply to check not just _completed but also _continuation. The operation is considered pending if either _completed is false, meaning SignalCompletion has not yet been called, or if _continuation is still null, meaning it's neither been set to the supplied delegate nor to the sentinel. We can't just rely on _completed for the above outlined reasons, and we can't just rely on _continuation because it can be non-null if OnCompleted was called to hook up a callback (if we only cared about the await pattern, then we could just check _continuation and wouldn't need _completed, but we also need to support non-await access).
* Address PR feedback
|
|
When awaiting a task, there's a race between seeing whether the task has completed (in which case we just continue running synchronously), finding the task hasn't completed (in which case we hook up a continuation), and then by the time we try to hook up the continuation finding the task has already completed. In that final case, we don't want to just execute the callback synchronously, as we risk a stack dive, so we queue it. That queueing currently entails two allocations in the common case: one for the work item object, and one for the Action delegate we force into existence for the state machine box's MoveNext method (in the common case it's now never allocated because you only await Tasks and ValueTasks known to the runtime, which bypasses its creation). We can instead just queue the box itself, and avoid both allocations.
|
|
It used to be that the CS0420 warning ("a reference to a volatile field will not be treated as volatile") would fire when a volatile was used with an Interlocked.* operation. That warning was unnecessary, as Interlocked.* would itself provide the relevant barriers, and these functions were special cased in Roslyn a long time ago. But there are still lots of places where pragmas disabling the warning have stuck around. I'm deleting them all.
|
|
When we unified the implementations of these across all of our runtimes, we lost all size optimizations people have been doing on the Project N side over the past six years.
This restores a bit of the loss. For one sample app with lots of async usage, this removes 2.1 MB of generic instantiations.
There is more we can do, but I can't spend time on that right now. These two things jumped out on me when I was looking at it back in December and were an easy fix I wanted to do for a while.
Signed-off-by: dotnet-bot <dotnet-bot@microsoft.com>
|
|
|
|
* Remove defunct netstandard code from ValueTask
* Remove several uses of VoidTaskResult
Currently TrySetResult/Canceled/Exception live on `Task<T>`. There's no reason `TrySetCanceled` and `TrySetException` need to live there, as they only access state from the base `Task`, and so can be moved down. `TrySetResult` needs the `TResult`, however in a variety of cases `Task<T>` is used with a `VoidTaskResult`, and for such cases we can just have a parameterless `TrySetResult()` on the base class as well, which can be used any time there is no `TResult` or when `default(TResult)` is the desired result. This lets us switch several cases where we were using `Task<VoidTaskResult>` to just be `Task`, which saves 8 bytes on the task instance on 64-bit. It also avoids an Interlocked.Exchange as part of the TrySetResult call.
This primarily affects Task.Delay and the non-generic variants of Task.WhenAll, ValueTask.AsTask(), Task.FromCanceled, and Task.FromException.
|
|
* Reduce Task's static ctor dependencies
* Remove defensive check
* Revert "Remove defensive check"
This reverts commit df15ab0350e8f44fc5cbb1a18c5211cd1de11989.
|
|
* Rename TplEtwProvider to TplEventSource
* Rename etwLog to log
|
|
* Move TaskContinuation to shared partition
* Remove TASK_STATE_THREAD_WAS_ABORTED from Task
* Use already existing ThrowAsync
|
|
|
|
|
|
|
|
Signed-off-by: dotnet-bot <dotnet-bot@microsoft.com>
|
|
|
|
|
|
arguments
Signed-off-by: dotnet-bot <dotnet-bot@microsoft.com>
|
|
* Move AsyncCausality to shared partition
* Set FeatureAsyncCausalityTracer property
|
|
|
|
* Use pattern matching `is` rather than `as` with null check
|
|
|
|
These are causing errors in the source.dot.net build. Turning on DocumentationFile and suppressing 1591, 1573, and 0419, Corelib builds clean after these changes.
|
