| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
* fix principal policy for new threads
Fixes #31717
Co-authored-by: Marco Rossignoli <marco.rossignoli@gmail.com>
|
|
|
|
The compiler is now analyzing statics. Get compliant.
|
|
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.)
|
|
Signed-off-by: dotnet-bot <dotnet-bot@microsoft.com>
|
|
Also update TODO-NULLABLE comments to be more specific where appropriate.
|
|
|
|
* Fix regression in Timers with long timeouts
Early in .NET Core 3.0, we added an important optimization to significantly reduce lock contention and CPU overheads in situations where lots of timers were firing. The optimization worked by splitting the set of timers into those expected to fire in the very near future and then everything else. However, for really long timers (e.g. > 24 days), due to integer overflows we can accidentally put a long timer onto the short list and cause a timer that shouldn’t fire for days to instead fire in milliseconds. This is not the first such bug we’ve had in Timer, and there is a fair amount of complicated casting (that we sometimes get wrong, obviously) in order to keep the tick count usage within the Int32 domain. This PR addresses the problem (and hopefully others in the future) by switching over to using Int64. We’re already paying to get 64-bit tick counts on both Windows and Unix, so this just removes truncation that was being performed, does a little more addition/comparison with 64-bit values instead of with 32-bit, and stores an Int64 instead of Int32 in each TimerQueueTimer. On 64-bit, this has a 0 increase in memory consumption, as it simply ends up utilizing padding space that was previously in TimerQueueTimer. On 32-bit, it increases memory allocation when creating a Timer by 4 bytes from 80 to 84 (still 3 allocations), but I believe it’s the right trade-off for reduced complexity and bug likelihood.
* Address PR feedback
|
|
(#25482)
Fixes https://github.com/dotnet/coreclr/issues/25242
- The issue could be that there is no memory barrier (or in the wrong place) on the thread reading the value, and an old value could be cached and read
|
|
|
|
|
|
* 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
|
|
|
|
|
|
* Track timer count and add Timer.Count
Part of https://github.com/dotnet/corefx/issues/38422
* Use lock to prevent tearing
* Add assert
* Rename Count to ActiveCount
* Fix build
|
|
|
|
Fix some nullable annotations from API Review
|
|
|
|
|
|
|
|
It's just StrongBox<T>.
|
|
|
|
Fixes #7452
Signed-off-by: dotnet-bot <dotnet-bot@microsoft.com>
|
|
* Add and apply nullable attributes
* Adapt to API review decisions
* Address PR feedback
|
|
SemaphoreSlim.Dispose nulls out its lock object, and that's then used as an indication in other methods whether they should throw ObjectDisposedException. But nulling out an object used for synchronization in other methods is a bad practice, and while SemaphoreSlim.Dispose is not thread-safe to be used concurrently with other usage of the instance, it's still confusing when such usage leads to NullReferenceExceptions due to trying to lock on a null lock object. This change just changes the lock to be readonly, always set, and then whether the instance has been disposed is just a value set on that object (such that it's no larger than it used to be).
|
|
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
|
|
This affects the case where SemaphoreSlim.WaitAsync is invoked, the operation completes asynchronously because there's no count available in the semaphore, and where a timeout and/or a cancellation token is passed to WaitAsync. In that case, we need to wait for the underlying wait task to complete, for cancellation to be requested, or for the timeout to elapse.
There's currently one code path that handles this. This change improves that slightly by avoiding a defensive array copy. However, we can do much better when we get a cancelable token but no timeout, in which case we can avoid operations like Task.Delay, can register with the original cancellation token rather than a new one (which means we avoid forcing a new CancellationTokenSource's lazily-allocated partitions into existence), etc.
|
|
* 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.
|
|
* Remove file polling only, and leave the COMPlus_* functionality.
* Fix bug/typo introduced with https://github.com/dotnet/coreclr/pull/21718
|
|
* Implement APIs for some threading metrics (CoreRT)
- API review: https://github.com/dotnet/corefx/issues/35500
- May depend on https://github.com/dotnet/coreclr/pull/22754
* Use thread-locals for counting, use finalizer instead of runtime to detect thread exit
* Don't let the count properties throw OOM
* Remove some flushes
Signed-off-by: dotnet-bot <dotnet-bot@microsoft.com>
|
|
respectively (master) (#24060)
* Update BuildTools, CoreClr to preview4-03917-01, preview5-27618-71, respectively
* Fix build errors
* Disable warning with pragma and linked issue
|
|
Implement APIs for some threading metrics (CoreCLR)
API review: https://github.com/dotnet/corefx/issues/35500
|
|
|
|
|
|
This compat quirk is increasingly more broken since the framework is generally not compatible with, and we have not heard anybody actually using it.
Changed Environment.HasShutdownStarted to unconditionally return false. It does not make sense for it to ever return true with shutdown finalization disabled.
|
|
Merge master into nullable branch
|
|
|
|
|
|
|
|
|
|
* Nullable: shared\System (most of it)
And some other things it touches.
* Nullable: src\System (most of it)
* Address PR feedback
|
|
|
|
|
|
|
|
|
|
|
