Inline remaining usages of OpenProcess on Unix#127795
Inline remaining usages of OpenProcess on Unix#127795am11 wants to merge 7 commits intodotnet:mainfrom
Conversation
dotnet-policy-service
Bot
added
the
community-contribution
jkotas
added
area-Diagnostics-coreclr
and removed
area-PAL-coreclr
|
Tagging subscribers to this area: @steveisok, @tommcdon, @dotnet/dotnet-diag |
|
|
||
| #ifdef TARGET_UNIX | ||
| // JIT-attach via CreateProcess + waitable process handle is Windows-only. Returning a | ||
| // failing HRESULT lets the calling code fall back to the standard hosting failure path. |
There was a problem hiding this comment.
What is the "standard hosting failure path" that this is talking about?
There was a problem hiding this comment.
Updated for clarification. It uses "no debugger attached" / unwind path on Unix.
I have done vscode testing on macOS, killing the process when debugger is running does give the same behavior as before. Though I'm not sure if that's conclusive / sufficient amount of testing? 👀 |
|
@janvorli, thanks for looking into it. I'm working on part B of this refactoring which will be in the next PR. It involves inlining wait subsystem usage at the callsite while deduplicating stuff, with massive cleanups in PAL; code would end up using the same familiar pthread APIs with minimum synchronization work. The sophisticated part of this Win32 emulation has been largely unused ever since the managed wait subsystem landed in .NET 11, so technically the remaining few native usages don't need to go through the PAL layer at all. Heads up that round 2 will likely need your and Tom's help running the internal diagnostics test suites against it. 🙂 |
|
@am11 that is awesome! |
|
@am11 the diagnostic tests have the same pass rate with and without your change. |
3 participants
Two usages of OpenProcess and one of OpenProcessMemory.
Follow-up: #127604 (comment).