Something with the same purpose of this was discussed here: Class for detecting unsafe operations in realtime contexts
which in turn is a spin-off of this other topic: Calling setValueNotifyingHost() from processBlock()
I think you should check those out because there are some very interesting considerations there.
In particular, I remember a consideration that struck me: like you did, my proposal was also to collect the IDs of those threads that are used for calling processBlock() and check agains those.
It was pointed out that it is entirely possible that the thread ids are reused, or that those same threads that for some time are allocated to audio processing, are later on used for other non-realtime stuff, and that would trigger any sort of false positive.
(you may deem such possibility as very improbable, but the #1 rule is to not make assumptions on how a DAW will behave. It’s almost the Murphy’s Law of Audio Plug-in Programming)
So, the proposal made by @jules turned out to be much more clean in my opinion, and it was simply to have a thread-local flag that is set right before every processBlock() call, and cleared immediately after it has returned. Kinda like a “scoped flag”.
At that point, “realtime-forbidden” operations should only check for that flag: if it is found to be set, then the operation is being performed in a realtime audio context and that should trigger the code that warns the developer, whatever it is (assertion, warning, etc.)