Define and implement behavior of NativeAOT EventPipe IPC if there's already another runtime in the process

[vitek-karas]

With NativeAOT it's more likely that there will be multiple runtimes in one process. For the most part this should work, but the IPC created by EventPipe is a process wide resource. We should define and implement the desired behavior.

My opinion:

• It should be possible to host multiple NativeAOT runtimes in a single process, with degraded diagnostics experience.
• One such solution would be that the component disables EventPipe during build, in which case it should just work
• I think it would be good that it still works even if EventPipe is enabled during build, it would simply "disable" itself if the IPC is already created by something else in the process. Effectively implementing a first one wins strategy.

@LakshanF

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

---

With NativeAOT it's more likely that there will be multiple runtimes in one process. For the most part this should work, but the IPC created by EventPipe is a process wide resource. We should define and implement the desired behavior.

My opinion:

• It should be possible to host multiple NativeAOT runtimes in a single process, with degraded diagnostics experience.
• One such solution would be that the component disables EventPipe during build, in which case it should just work
• I think it would be good that it still works even if EventPipe is enabled during build, it would simply "disable" itself if the IPC is already created by something else in the process. Effectively implementing a first one wins strategy.

@LakshanF

Author:	vitek-karas
Assignees:	-
Labels:	area-NativeAOT-coreclr
Milestone:	-

[LakshanF]

We have a first win strategy in place right now after #91715. Our guidance for EventSource/EventPipe with native AOT shared libraries is as follows

• Only use the EventSourceSupport enabled when troubleshooting a specific issue related to shared libraries.
• Any native AOT console with EventSourceSupport enabled will always win even if the process has other native AOT shared libraries with EventSourceSupport enabled.
• If there are multiple native AOT shared libraries present in a single process, then the first shared library that gets loaded will win to emit traces. Traces from other libraries will not be seen.
• [Windows] When collecting tracing in a shared library, collection should stop earlier in the application (only collect for a specific time period or use the ctrl-C option with a tool like dotnet-trace when the interesting traces are collected). Specifically, in windows, the image unload event for a shared library (or at process exit), will not make a call to shut down the EventPipe in an orderly manner, causing a corrupted trace file.

Given these challenges, it's probably best to keep the current warnings we have for shared library around EventSource support.

[MichalStrehovsky]

Before closing this out, we should make sure there is a test ensuring the first win strategy works and we don't get e.g. a bad crash (now, or in the future).