[threads] Add back mono_threads_attach_tools_thread as a public API (mono/mono#18048)
authorAleksey Kliger (λgeek) <alklig@microsoft.com>
Fri, 6 Dec 2019 15:50:34 +0000 (10:50 -0500)
committerGitHub <noreply@github.com>
Fri, 6 Dec 2019 15:50:34 +0000 (10:50 -0500)
commit45a050fd8ec0b556ca17e788345d4bf85b647a51
tree3625a188e34a855ea14a1cdf59fc89db19ed18a9
parentbe808b7e83bee650f6be4d61e6abf6580c00addc
[threads] Add back mono_threads_attach_tools_thread as a public API (mono/mono#18048)

* [utils] Add back mono_threads_attach_tools_thread

In https://github.com/mono/mono/commit/mono/mono@a5da7b21f4b6dbc5eaa09c2addee91b84dc1dbd5
we got rid of "tools" threads internally to the runtime.

However since the API was previously marked with MONO_API it was an internal
API that some embedders depended on.

This PR adds back an (external-only) limited form of tools thread.

The runtime is aware of the Tools thread in that FOREACH_THREAD_* macros will
iterate over them, and the thread has a coop thread state machine. (That is,
mono_thread_info_current() and GC Safe and GC Unsafe transitions all work.)

However the thread is:
1. Not stopped by the GC
2. Is not interrupted by profiler sampling.
3. Does not have a "current domain"
4. (As a consequence of the above) cannot call managed methods or touch managed
objects.

Such threads are useful for low-level interaction with the runtime such as
querying metadata, the JIT state and other coordination.

mono_threads_attach_tools_thread should be called no more than once.  It should
not be called on a thread that is already attached with mono_thread_atach, and
vice versa.

Addresses https://github.com/mono/mono/issues/18011

* [threads] Make mono_threads_attach_tools_thread into a public API

Commit migrated from https://github.com/mono/mono/commit/3dabeddfc65e11ece3a4d089a2796f8da850c881
src/mono/mono/metadata/threads.c
src/mono/mono/metadata/threads.h