[threads] Add back mono_threads_attach_tools_thread as a public API#18048
[threads] Add back mono_threads_attach_tools_thread as a public API#18048lambdageek merged 2 commits intomono:masterfrom
Conversation
In mono@a5da7b2 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 mono#18011
|
This is enough to get the sample from https://github.com/lambdageek/mono-mach-exceptions working. Another option is to do stuff with mach ports in Mono directly and provide a mach exception hook that an embedder can register. We'd probably have to expose a function like: where |
|
Is it really a good idea to take a stance of supporting legacy APIs just because they happened to be exported from It seems to me that if these APIs are needed by embedders, then they should be properly promoted to an actual public header with the support commitment that goes with that. |
That's true. |
|
Made it a public API |
0e7db0d to
a00b5bb
Compare
|
@monojenkins build failed |
a00b5bb to
c6b6dba
Compare
|
@monojenkins backport to 2019-12 |
|
@monojenkins backport to 2019-10 |
…ono/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 mono/mono#18011 * [threads] Make mono_threads_attach_tools_thread into a public API Commit migrated from mono/mono@3dabedd
In a5da7b2
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:
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 #18011