# AudioThreadGuard - keep your audio thread clean

**URL:** <https://forum.juce.com/t/audiothreadguard-keep-your-audio-thread-clean/28532>\
**Category:** Useful Tools and Components\
**Created:** [July 13, 2018, 11:49am UTC](https://forum.juce.com/t/audiothreadguard-keep-your-audio-thread-clean/28532 "2018-07-13T11:49:30Z")\
**Posts on this page:** 1\
**Showing post:** 12

<div class="post-metadata">

**Author:** ![yfede](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/yfede/32/506_2.png) [@yfede](https://forum.juce.com/u/yfede)\
**Post date:** [July 20, 2018, 7:52am UTC](https://forum.juce.com/t/audiothreadguard-keep-your-audio-thread-clean/28532/12 "2018-07-20T07:52:02Z")

</div>

Something with the same purpose of this was discussed here: [Class for detecting unsafe operations in realtime contexts](https://forum.juce.com/t/class-for-detecting-unsafe-operations-in-realtime-contexts/26330)  
which in turn is a spin-off of this other topic: [Calling setValueNotifyingHost() from processBlock()](https://forum.juce.com/t/calling-setvaluenotifyinghost-from-processblock/26073)

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.)

---

_[View the full topic](https://forum.juce.com/t/audiothreadguard-keep-your-audio-thread-clean/28532)._