[NativeAOT] Revisit process/thread termination scenario

[VSadov]

Re: #74679

A few concerns that we need to address before supporting more scenarios.

• there is a number of mechanisms that require that thread exit is promptly communicated to the runtime. For example Unix wait susbsystem releases locks held by the thread. As a result we cannot rely on finalization of Thread object as that can be delayed or not run at all.
  Verify if this requirement is reasonable and unavoidable.
• the code that performs pre-mortem tasks for a thread is managed. That is not an issue for threads created by the runtime as the entry point can call into "OnExit" routine (this is not what we do though).
  For the threads that are created natively and then attached to the runtime (typically by performing a reverse pinvoke), the issue is more interesting. There is a number of ways how the OS can do a thread exit notification callback, but it may come with restrictions such as holding system locks.
• at some point in process termination sequence threads may be rudely stopped, making it risky to run any code as the threads can leave spinlocks locked and/or cause unpredictable behavior.
  Is it possible to be more robust here? This could be very OS-specific.
• currently the Thread objects are stored directly in the thread's TLS and form a linked list. That requires that a thread is self-removed from the list as long as we may be iterating the list as once OS releases the thread's TLS, the list could become corrupted. Removal from the list must take a lock.
  This causes inconvenience in process shutdown scenarios if we may want to ignore thread exits, yet we must remove from the list.

Also consider

• possibility of loading/hosting NativeAOT libraries in native processes, possibly multiple libraries in the same process.
• process shutdown initiated via native "ProcessExit" or the OS equivalent
• "ProcessExit" possibly called multiple times on multiple threads.

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Re: #74679

A few concerns that we need to address before supporting more scenarios.

• there is a number of mechanisms that require that thread exit is promptly communicated to the runtime. For example Unix wait susbsystem releases locks held by the thread. As a result we cannot rely on finalization of Thread object.
  Verify if this is reasonable and unavoidable.
• the code that performs pre-mortem tasks for a thread is managed. That is not an issue for threads created by the runtime as the entry point can call into "OnExit" routine (this is not what we do though).
  For the threads that are created natively and then attached to the runtime, the issue is more interesting. There is a number of ways how the OS can do a thread exit notification callback, but it may come with restrictions such as holding system locks.
• at some point in process termination sequence threads may be rudely stopped making it risky to run any code lest the threads can eave spinlocks locked and/or cause unpredictable behavior.
  Is it possible to be more robust here? This could be very OS-specific.
• currently the Thread object is stored on the thread's stack. That requires that a thread is self-removed from the list as long as we may be iterating the list as once OS releases the thread's stack, the list could become corrupted. Removal from the list must take a lock.
  This causes inconvenience in process shutdown scenarios if we may want to ignore thread exits.

Also consider

• possibility of loading/hosting NativeAOT libraries in native processes, possibly multiple libraries in the same process.
• process shutdown initiated via native "ProcessExit" or the OS equivalent
• "ProcessExit" possibly called multiple times on multiple threads.

Author:	VSadov
Assignees:	-
Labels:	area-System.Threading
Milestone:	Future

[VSadov]

One interesting scenario on OSX - #75264 (comment)