Skip to content

Turn repeated thread locality content into an include #11554

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.

Sign up for GitHub

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

Merged
merged 2 commits into from
Nov 21, 2024
Merged

Turn repeated thread locality content into an include #11554

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
f4a5808
Turn repeated thread locality content into an include
Oct 11, 2024
a86c11c
Update includes/platforms/configuration/options/thread-locality.mdx
jamescrosswell Nov 7, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 1 addition & 18 deletions docs/platforms/dotnet/common/enriching-events/scopes/index.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -34,24 +34,7 @@ other hand are more user facing. You can call <PlatformIdentifier name="configur
time to modify data stored on the scope. This is useful for doing things like
[modifying the context](../context/).

<Alert>

If you are very curious about how thread locality works for scope data, in .NET there
are two modes for managing "ambient data". Usuaully Sentry will automatically choose the
most appropriate mode for your application type. However this can be overridden by
setting [`SentryOptions.IsGlobalModeEnabled`](../../configuration/options/#is-global-mode-enabled) manually.

If global mode is disabled (appropriate for most server based applications), the
ambient scope data is stored as an `AsyncLocal` and so it will flow with the execution
context. Stephen Toub's blog post on [ExecutionContext vs SynchronizationContext](https://devblogs.microsoft.com/pfxteam/executioncontext-vs-synchronizationcontext/)
explains that concept in more detail.

If global mode is enabled (appropriate for desktop applications), ambient scope data is
stored as a Singleton and available globally. This means you can set context (such as
the user logged into the application) once and it will be sent with all events, regardless
of whether the event was captured on the UI thread or a background thread.

</Alert>
<Include name="platforms/configuration/options/thread-locality.mdx" />

When you call a global function such as <PlatformIdentifier name="capture-event" /> internally Sentry
discovers the current hub and asks it to capture an event. Internally the hub will
Expand Down
19 changes: 1 addition & 18 deletions docs/platforms/powershell/enriching-events/scopes/index.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -34,24 +34,7 @@ other hand are more user facing. You can call <PlatformIdentifier name="configur
time to modify data stored on the scope. This is useful for doing things like
[modifying the context](../context/).

<Alert>

If you are very curious about how thread locality works for scope data, in .NET there
are two modes for managing "ambient data". Usuaully Sentry will automatically choose the
most appropriate mode for your application type. However this can be overridden by
setting [`SentryOptions.IsGlobalModeEnabled`](../../configuration/options/#is-global-mode-enabled) manually.

If global mode is disabled (appropriate for most server based applications), the
ambient scope data is stored as an `AsyncLocal` and so it will flow with the execution
context. Stephen Toub's blog post on [ExecutionContext vs SynchronizationContext](https://devblogs.microsoft.com/pfxteam/executioncontext-vs-synchronizationcontext/)
explains that concept in more detail.

If global mode is enabled (appropriate for desktop applications), ambient scope data is
stored as a Singleton and available globally. This means you can set context (such as
the user logged into the application) once and it will be sent with all events, regardless
of whether the event was captured on the UI thread or a background thread.

</Alert>
<Include name="platforms/configuration/options/thread-locality.mdx" />

When you call a global function such as <PlatformIdentifier name="capture-event" /> internally Sentry
discovers the current hub and asks it to capture an event. Internally the hub will
Expand Down
19 changes: 1 addition & 18 deletions docs/platforms/unity/enriching-events/scopes/index.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -34,24 +34,7 @@ other hand are more user facing. You can call <PlatformIdentifier name="configur
time to modify data stored on the scope. This is useful for doing things like
[modifying the context](../context/).

<Alert>

If you are very curious about how thread locality works for scope data, in .NET there
are two modes for managing "ambient data". Usuaully Sentry will automatically choose the
most appropriate mode for your application type. However this can be overridden by
setting [`SentryOptions.IsGlobalModeEnabled`](../../configuration/options/#is-global-mode-enabled) manually.

If global mode is disabled (appropriate for most server based applications), the
ambient scope data is stored as an `AsyncLocal` and so it will flow with the execution
context. Stephen Toub's blog post on [ExecutionContext vs SynchronizationContext](https://devblogs.microsoft.com/pfxteam/executioncontext-vs-synchronizationcontext/)
explains that concept in more detail.

If global mode is enabled (appropriate for desktop applications), ambient scope data is
stored as a Singleton and available globally. This means you can set context (such as
the user logged into the application) once and it will be sent with all events, regardless
of whether the event was captured on the UI thread or a background thread.

</Alert>
<Include name="platforms/configuration/options/thread-locality.mdx" />

When you call a global function such as <PlatformIdentifier name="capture-event" /> internally Sentry
discovers the current hub and asks it to capture an event. Internally the hub will
Expand Down
16 changes: 16 additions & 0 deletions includes/platforms/configuration/options/thread-locality.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,16 @@
<Alert>

Read on if you're curious to know how thread locality works for scope data. In .NET, there
are two modes for managing ambient data (which is data that's available in different parts of an application and doesn't need to be passed explicitly through method arguments): a disabled global mode and an enabled global mode. Usually, Sentry will automatically choose the most appropriate mode for your application type. However, this can be overridden by setting [`SentryOptions.IsGlobalModeEnabled`](../../configuration/options/#is-global-mode-enabled) manually.

If global mode is disabled (appropriate for most server-based applications), the
ambient scope data will be stored as an `AsyncLocal` and will flow with the execution
context. Stephen Toub's blog post on [ExecutionContext vs SynchronizationContext](https://devblogs.microsoft.com/pfxteam/executioncontext-vs-synchronizationcontext/)
explains that concept in more detail.

If global mode is enabled (appropriate for desktop applications), ambient scope data will be
stored as a Singleton and available globally. This means you can set context (such as
the user logged into the application) once and it will be sent with all events, regardless
of whether the event was captured on the UI thread or a background thread.

</Alert>
Loading