# signalThreadShouldExit & startThread **URL:** \ **Category:** General JUCE discussion\ **Created:** [December 5, 2017, 10:37am UTC](https://forum.juce.com/t/signalthreadshouldexit-startthread/25437 "2017-12-05T10:37:48Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![railjonrogut](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/railjonrogut/32/505_2.png) [@railjonrogut](https://forum.juce.com/u/railjonrogut)\ **Post date:** [December 5, 2017, 10:37am UTC](https://forum.juce.com/t/signalthreadshouldexit-startthread/25437/1 "2017-12-05T10:37:48Z")
If you have a Thread and flag it to Exit with signalThreadShouldExit() and then startThread() fairly quickly… the Thread may not start… I’ve written my own code to make sure the thread isn’t running before trying to startThread()… but shouldn’t startThread() check if the _shouldExit_ flag is set and if the thread is already running… wait for it to stop before starting the Thread? Cheers, Rail ---
**Author:** ![daniel](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/daniel/32/790_2.png) [@daniel](https://forum.juce.com/u/daniel)\ **Post date:** [December 5, 2017, 11:02am UTC](https://forum.juce.com/t/signalthreadshouldexit-startthread/25437/2 "2017-12-05T11:02:29Z")
> [@Rail\_Jon\_Rogut](#): > > and if the thread is already running… wait for it to stop before starting the Thread? I would rather expect it to not trying to start the thread, because otherwise you wait in the startThread for the stopThread… sounds like you _could_ get into infinite problems… ---
**Author:** ![railjonrogut](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/railjonrogut/32/505_2.png) [@railjonrogut](https://forum.juce.com/u/railjonrogut)\ **Post date:** [December 5, 2017, 11:08am UTC](https://forum.juce.com/t/signalthreadshouldexit-startthread/25437/3 "2017-12-05T11:08:34Z")
If you’re waiting for it to not be running before you try and start the Thread… I don’t see how you could get into a loop 😉 Rail ---
**Author:** ![t0m](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/t0m/32/16413_2.png) [@t0m](https://forum.juce.com/u/t0m)\ **Post date:** [December 5, 2017, 11:15am UTC](https://forum.juce.com/t/signalthreadshouldexit-startthread/25437/4 "2017-12-05T11:15:23Z")
Why are you using `signalThreadShouldExit` rather than `stopThread`? ---
**Author:** ![daniel](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/daniel/32/790_2.png) [@daniel](https://forum.juce.com/u/daniel)\ **Post date:** [December 5, 2017, 11:17am UTC](https://forum.juce.com/t/signalthreadshouldexit-startthread/25437/5 "2017-12-05T11:17:30Z")
> [@Rail\_Jon\_Rogut](#): > > I don’t see how you could get into a loop 😉 yes, I am aware, that’s why I put could and in italic, to put double doubt in it. But waiting for something to stop to schedule it to start sounds strange to me, and depending how this workflow is triggered it ends up waiting for on and of. It sounds like Adrian Monk switching the light switch on and off 5 times, before he can leave the flat… ---
**Author:** ![railjonrogut](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/railjonrogut/32/505_2.png) [@railjonrogut](https://forum.juce.com/u/railjonrogut)\ **Post date:** [December 5, 2017, 11:23am UTC](https://forum.juce.com/t/signalthreadshouldexit-startthread/25437/6 "2017-12-05T11:23:53Z")
> [@t0m](#): > > Why are you using signalThreadShouldExit rather than stopThread? Why would that matter? stopThread() calls signalThreadShouldExit() (and I don’t necessarily want to wait for it to stop… I don’t always start the Thread again right away) ?? Cheers, Rail ---
**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\ **Post date:** [December 5, 2017, 11:31am UTC](https://forum.juce.com/t/signalthreadshouldexit-startthread/25437/7 "2017-12-05T11:31:44Z")
> [@Rail\_Jon\_Rogut](#): > > but shouldn’t startThread() check if the shouldExit flag is set and if the thread is already running… wait for it to stop before starting the Thread? I don’t think so, though exactly what it should do probably does need defining more clearly. What happens at the moment is that startThread resets the exit flag regardless of whether or not there’s a thread currently running. If one is already running, then it returns, so if you were to call signalThreadShouldExit and then startThread quickly, the existing thread may carry on running if it doesn’t check the flag in time. But yes, you could hit a race condition if startThread resets the flag, and then the thread exits before it gets chance to check whether the thread is still running. However, is that actually wrong? If the startThread method had executed fractionally sooner then the result would be the same anyway. There are a whole bunch of subtle edge cases here and I’m not sure there’s an obviously “correct” behaviour, so thoughts welcome! ---
**Author:** ![railjonrogut](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/railjonrogut/32/505_2.png) [@railjonrogut](https://forum.juce.com/u/railjonrogut)\ **Post date:** [December 5, 2017, 11:38am UTC](https://forum.juce.com/t/signalthreadshouldexit-startthread/25437/8 "2017-12-05T11:38:17Z")
Let me explain my use case… I have a Groove player with a PlayHead (insertion point)… and if you mouse click in the timeline while in playback - playback is stopped… ``` m_PlayheadThread.signalThreadShouldExit(); ``` and after the new location is calculated, playback is re-started from the position where the click occurred in the Timeline… ``` m_PlayheadThread.startThread (PLAYHEADTHREADPRIORITY); ``` However, playback can also be started and stopped by using the spacebar or the Play/Stop button. If I check the m\_bIsPlaying flag and m\_PlayheadThread.isThreadRunning() I can wait before starting the Thread. Without checking the flag and if the Thread was still running, it would not always restart - so the Insertion Point would stop moving. Cheers, Rail ---
**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\ **Post date:** [December 5, 2017, 11:41am UTC](https://forum.juce.com/t/signalthreadshouldexit-startthread/25437/9 "2017-12-05T11:41:06Z")
TBH I wouldn’t use the thread being started or stopped to represent play state. Starting/stopping involves a fair bit of overhead - better to keep a thread running all the time, and just use a flag (or message queue) to give it instructions about whether to play or stop. ---
**Author:** ![railjonrogut](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/railjonrogut/32/505_2.png) [@railjonrogut](https://forum.juce.com/u/railjonrogut)\ **Post date:** [December 5, 2017, 11:43am UTC](https://forum.juce.com/t/signalthreadshouldexit-startthread/25437/10 "2017-12-05T11:43:52Z")
well in general when the user clicks the Play/Stop button I want the Thread to start/stop running… so it’s not running when there’s no groove playing (and it’s getting external MIDI triggers)… so I’m re-using the same methods… and it seems to work really well… so I’m not sure I want to change it 😉 Cheers, Rail ---
**Author:** ![t0m](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/t0m/32/16413_2.png) [@t0m](https://forum.juce.com/u/t0m)\ **Post date:** [December 5, 2017, 11:54am UTC](https://forum.juce.com/t/signalthreadshouldexit-startthread/25437/11 "2017-12-05T11:54:58Z")
Well then I think doing ``` m_PlayheadThread.signalThreadShouldExit(); ``` then ``` m_PlayheadThread.stopThread (timeout); m_PlayheadThread.startThread (PLAYHEADTHREADPRIORITY); ``` will achieve what you want. Most of the time `stopThread` will be nearly instantaneous (as the previous call to `signalThreadShouldExit` will have stopped the thread already), but it will wait if required. Jules’ suggestion is the way to go though. ---
**Author:** ![railjonrogut](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/railjonrogut/32/505_2.png) [@railjonrogut](https://forum.juce.com/u/railjonrogut)\ **Post date:** [December 5, 2017, 12:14pm UTC](https://forum.juce.com/t/signalthreadshouldexit-startthread/25437/12 "2017-12-05T12:14:04Z")
Right, I already have a work-around… I just thought it may be something that startThread() should check… but that’s up to y’all. It just seemed wrong that I needed to deal with it. Cheers, Rail ---
**Author:** ![daniel](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/daniel/32/790_2.png) [@daniel](https://forum.juce.com/u/daniel)\ **Post date:** [December 5, 2017, 12:21pm UTC](https://forum.juce.com/t/signalthreadshouldexit-startthread/25437/13 "2017-12-05T12:21:59Z")
I think all is said, but for the records, if you use the BufferingAudioSource, they use the [TimeSliceThread](https://juce.com/doc/classTimeSliceThread), which uses a [WaitableEvent](https://juce.com/doc/classWaitableEvent) semaphore. So if it the sources are not pulling audio, the threads are using no resources at all, without stopping and restarting them… ---
**Author:** ![kunitoki](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/kunitoki/32/15_2.png) [@kunitoki](https://forum.juce.com/u/kunitoki)\ **Post date:** [December 5, 2017, 12:34pm UTC](https://forum.juce.com/t/signalthreadshouldexit-startthread/25437/14 "2017-12-05T12:34:10Z")
I wouldn’t start and stop a thread from user interaction like this, better to have the thread running but paused on a condition or waitable. This way it’s safer to control and lighter on resources. ---
**Author:** ![railjonrogut](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/railjonrogut/32/505_2.png) [@railjonrogut](https://forum.juce.com/u/railjonrogut)\ **Post date:** [December 5, 2017, 7:05pm UTC](https://forum.juce.com/t/signalthreadshouldexit-startthread/25437/15 "2017-12-05T19:05:52Z")
Okay - I just paused the Thread on a mouse click… when I start and stop using the play button or the space bar I stop/start the Thread. Cheers, Rail