Pulled modules branch, compiled introjucer, runned it and pressed “Check for available updates blah blah…” then freezed for some seconds:
kraken@klang ~/Projects/juce-trunk/extras/Introjucer/Builds/Linux $ build/Introjucer
JUCE Assertion failure in ../../../../modules/juce_core/threads/juce_Thread.cpp, line 256
!! killing thread by force !!
JUCE Assertion failure in ../../../../modules/juce_gui_basics/widgets/juce_TextEditor.cpp, line 1242
after some other minutes an alert popped up saying cannot connect to juce web server…
The violence must be stopped!
It was some time i had to check all this introjucer + modules stuff, and it exploded ungracefully in my hands the first time i fired…
wtf indeed… Very hard to guess what might have gone wrong there! Maybe the website was down - that’s not a situation I’ve tested it in yet.
even if the website was down… the killing thread by force should not happen in all cases !
I agree! It’s very new code though, give me a chance!
I wish there was a macro to turn off the variables with global scope which keep a list of all juce::Thread objects and try to kill them on exit. I’m a big boy, I don’t need this feature.
but it doesn’t try to stop all the theads on exit…? Sure, there’s a Thread::stopAllThreads method, but it’s never called by the library.
Hmm…then it would be nice if there could be a juce::Thread constructor parameter “bool addToGlobalList” which defaults to ‘true’, which I could explicitly construct with false. I get tricky interactions with this global list using a juce::Thread during some of my initialization and shutdown code, which resembles a library in the sense that there are objects with static storage duration that use juce elements.