perf: add support for batched scope access

[jpnurmi]

Keep the scope read or write lock across a batch while allowing the owning thread to use existing scope accessors without relocking.

This tackles two use-cases:

• Atomic reads of multiple scope properties: don't allow writes from other threads to intervene to ensure consistent data
• Batched writes of multiple scope properties: one backend flush at the end can result in huge wins in terms of performance

[cursor]

Stale Bugbot comment from a previous run.

[codecov]

Codecov Report

❌ Patch coverage is 88.05970% with 16 lines in your changes missing coverage. Please review.
✅ Project coverage is 75.57%. Comparing base (c77cb6e) to head (bf866ff).

Additional details and impacted files

@@                       Coverage Diff                        @@
##           jpnurmi/ref/scope-flush-func    #2107      +/-   ##
================================================================
+ Coverage                         75.55%   75.57%   +0.01%     
================================================================
  Files                               103      103              
  Lines                             28171    28292     +121     
  Branches                           5159     5179      +20     
================================================================
+ Hits                              21286    21383      +97     
- Misses                             5530     5560      +30     
+ Partials                           1355     1349       -6     

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 0083711. Configure here.}

[jpnurmi]

@limbonaut @tustanivsky some potential candidates for write-locked batch updates that would fold several flushes into one:

• Unreal: FGenericPlatformSentryScope::Apply
• Godot: SentrySDK::_init_contexts

[limbonaut]

Looks really neat! 🚢 🗺️
Q: Can users use these with the global scope? Probably need either sentry_begin_write or an actual accesor for the global scope.

[jpnurmi]

Q: Can users use these with the global scope? Probably need either sentry_begin_write or an actual accesor for the global scope.

Which would you prefer? With sentry_begin_write we'd get away without exposing the global scope and dealing with the consequences just yet, but a global sentry_begin_write reads somewhat awkwardly compared to sentry_scope_begin_write... 🤔

[limbonaut]

It can also be a more explicit name such as sentry_global_scope_begin_write.
I'm not sure what kind of traps we are facing when it comes to exposing an actual accessor.

[jpnurmi]

I'm not sure what kind of traps we are facing when it comes to exposing an actual accessor.

Hmmm, now that I think of it, we might have coincidentally eliminated the blocker problems with the recent RW-lock changes.

Before, all global scope access was exclusively locked during SENTRY_WITH_SCOPE macro blocks, and accessing the global scope anywhere outside of those blocks would not have been safe. Now, with RW-locks, any global or local scope instance protects its own data, so it's basically safe to access them anywhere as long as the instance itself is safely ref-counted.

Exposing the global scope is tempting because it would allow being more selective with the global vs. scope API duplication going forward... 🤔

[limbonaut]

Now, with RW-locks, any global or local scope instance protects its own data, so it's basically safe to access them anywhere as long as the instance itself is safely ref-counted.

I think you are right. Something like sentry_get_scope() could be a good name. Eventually, we may want to support isolation scopes, and these API calls would automatically work with such too.