Today, we use WaitForMultipleObjectsEx on Windows and non-Windows with multiple events/wait handles (including a process handle) in the debugger-runtime communication. This is the last usage of multiple events (and waiting on a process handle) with this CoreCLR PAL API. Once we remove this, we can remove the native wait subsystem and replace with a simple xplat implementation a-la NativeAOT's CLREvent that only supports WaitForMultipleObjectsEx with one event on non-Windows.
We can replace the handles and the usage with an xplat design in the CoreCLR minipal (or the repo minipal) that has the following implementations for this constrained use case:
Win32: Win32 Wait Handles
Linux: anonymous pipes + select (using pidfd_open when available, otherwise with an auxiliary thread for waiting for the process as exists today in the wait subsystem)
MacOS (and also all BSD platforms): kqueue
cc: @hoyosjs
Today, we use
WaitForMultipleObjectsExon Windows and non-Windows with multiple events/wait handles (including a process handle) in the debugger-runtime communication. This is the last usage of multiple events (and waiting on a process handle) with this CoreCLR PAL API. Once we remove this, we can remove the native wait subsystem and replace with a simple xplat implementation a-la NativeAOT's CLREvent that only supportsWaitForMultipleObjectsExwith one event on non-Windows.We can replace the handles and the usage with an xplat design in the CoreCLR minipal (or the repo minipal) that has the following implementations for this constrained use case:
Win32: Win32 Wait Handles
Linux: anonymous pipes + select (using
pidfd_openwhen available, otherwise with an auxiliary thread for waiting for the process as exists today in the wait subsystem)MacOS (and also all BSD platforms): kqueue
cc: @hoyosjs