-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Breaking change] Changing EventSource OnEventCommand to be consistent #84586
Labels
area-Tracing-coreclr
breaking-change
Issue or PR that represents a breaking API or functional change over a prerelease.
Comments
davmason
added
breaking-change
Issue or PR that represents a breaking API or functional change over a prerelease.
area-Tracing-coreclr
labels
Apr 10, 2023
ghost
added
untriaged
New issue has not been triaged by the area owner
needs-breaking-change-doc-created
Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet
labels
Apr 10, 2023
Added
Tagging @dotnet/compat for awareness of the breaking change. |
CC @dotnet/dotnet-diag @jeffschwMSFT |
Actually CC @dotnet/dotnet-diag (typo the first time) |
This was referenced Apr 12, 2023
tommcdon
removed
the
needs-breaking-change-doc-created
Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet
label
May 17, 2023
Closing this since we have the breaking change doc bugs created |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
area-Tracing-coreclr
breaking-change
Issue or PR that represents a breaking API or functional change over a prerelease.
PR #82970 was a fix for issue #61353, it included a minor breaking change in that we make the callback for
EventSource.OnEventCommand
after we mark all events as disabled.Previous behavior
Prior to this change, we would issue the
EventSource.OnEventCommand
callback for aEventCommand.Disable
prior to settingm_eventSourceEnabled=false
. This means thatIsEnabled
would return true in theOnEventCommand
callback for a userEventSource
, even if the command would lead to theEventSource
being disabled.The callback happens after we turn off the ability to dispatch events though, so even if an
EventSource
tries to fire an event it will not be written. Also, forEventCommand.Enable
we issue a consistent view -IsEnabled
accurately reports the state of the world, and theEventSource
can write events from theOnEventCommand
callback. This change makes theEventCommand.Disable
behavior match theEnable
behavior.New behavior
The change makes the callbacks consistent, now we will mark the
EventSource
as disabled before the callback.@PriyaPurkayastha - We have multiple first party requests to backport this fix to 6.0 and 7.0, I would appreciate guidance on how to proceed with the backports. Is documentation sufficient?
The text was updated successfully, but these errors were encountered: