[sgen] Transition to GC Unsafe in mono_gc_wait_for_bridge_processing #55681
Conversation
Mark it as an external only API. In the runtime, use mono_gc_wait_for_bridge_processing_internal.
|
Tagging subscribers to this area: @BrzVlad Issue DetailsMark it as an external only API. In the runtime, use
|
lambdageek
force-pushed
the
wait-for-bridge-external-api
branch
from
f4ca1a3 to
e32e454
Compare
| @@ -103,7 +103,7 @@ typedef struct { | |||
| */ | |||
| MONO_API void mono_gc_register_bridge_callbacks (MonoGCBridgeCallbacks *callbacks); | |||
|
|
|||
| MONO_API void mono_gc_wait_for_bridge_processing (void); | |||
| MONO_API MONO_RT_EXTERNAL_ONLY void mono_gc_wait_for_bridge_processing (void); | |||
There was a problem hiding this comment.
I assume this MONO_RT_EXTERNAL_ONLY thing is to mark it as something that should only be called externally, not by the runtime itself? Is there some static checking that prevents such calls?
There was a problem hiding this comment.
It expands to an __attribute__((deprecated)) when it's compiled inside the runtime, so we get a build error.
the general pattern we've been following with GC Unsafe transitions in MONO_API functions is that we add an _internal vesion which doesn't do the transition (because inside the runtime we're in GC Unsafe mode most of the time and do transitions explicitly), and an external-only API function that performs the transition explicitly because they are primarily called from outside the runtime which is mostly in GC Safe mode. (transitions to enter unsafe are ok to nest, so it would be harmless to dispense with the _internal function, but it's a bit nicer to avoid the extraneous function call)
|
/azp run sync-runtime-to-mono |
1 similar comment
|
/azp run sync-runtime-to-mono |
ghost
locked as resolved and limited conversation to collaborators
Mark it as an external only API. In the runtime, use
mono_gc_wait_for_bridge_processing_internal