Very exciting for sure! Thank you for this release!
Question, since the multithread feature is beta… Is there any risks using it (memory leaks/crashes/etc)?
Memory leaks have been tested for, but certainly there will be less RAM until we tune the system more rigorously and there is the possibility of crashes, particularly when entering/existing listening mode, or with code interacting in ways that couldn’t happen before.
All of this only when SYSTEM_THREAD(ENABLED) is added - without system threading the firmware is intended to be at least as stable as 0.4.5, if not more so due to the various fixes added.
@mdma, This is so COOL! This is available for local building only I assume at this point? When do you expect the Web IDE to be updated?
0.4.6 is already in the web IDE 
Does this affect code which was previously stopped when there is no Wi-Fi connection ?
e.g. Will my code run now with no Wi-Fi when it would not run in previous releases ?
It’s funny you mention this blinky example, I have a similar piece of code in an IRQ that responds to the magnetic reed switch in an anemometer - this code blinked (flipped the state of) the LED in 0.4.5, but does not blink the LED at all in 0.4.6:
int BLINK = D7;
void wirq()
{
# other logic to increment a value here
digitalWrite(BLINK, (digitalRead(BLINK) == HIGH? LOW : HIGH));
}
I haven’t put much time into trying to figure out why, but I will probably try your way of writing it (as it’s easier to read anyway). I didn’t know that HIGH and LOW are actually synonyms for true/false
Yes your code will now run and run and run, while the Wi-Fi does whatever it needs to do to maintain a connection 
Run @mdma’s example above and you’ll be so amaze!!!
I just ran this code and it works fine, can you try this one?
SYSTEM_THREAD(ENABLED);
void setup()
{
pinMode(D7, OUTPUT);
}
void loop()
{
//digitalWrite(D7, !digitalRead(D7));
digitalWrite(D7, (digitalRead(D7) == HIGH? LOW : HIGH));
delay(100);
}
I did a test via a hotspot and noticed that the Photon does a SOS once I kill the hotspot.
Not sure if its related to the hotspot or if the same behavior will happen on a regular router as well.
What is the number of blinks after the SOS?
I just tried blocking Wi-Fi by removing my external antenna on my u.FL only photon (chip ant removed), and then covered my hands around it to completely weaken the RF it sees… it would blink CYAN for a bit, then drop back to blinking GREEN. When I reconnect my external antenna the connection is restored very quickly. Best part is watching that D7 LED blink steadily the entire time
I’ll try actually switching off my Internet connection in my router in a little bit and see if there’s any difference.
Does this SOS happen with threading disabled? If I can request that everyone who finds a problem also checks with threading disabled that will help us a lot in narrowing down the problem.
Works fine with threading disabled. Goes immediately flashing green once I kill the hotspot.
Thanks for that! I’m not surprised there are some issues like this, I will add it to our known threading problems. (That’s why this is released as Beta!)
1 Like
Is there any reason this shouldn’t work via local build? I’ve run Git Pull to update my local repository but at compile time I get the error
error: expected constructor, destructor, or type conversion before '(' token
SYSTEM_THREAD(ENABLED);
I’ve put it just above my void setup() call as in your example.
Fixed it, just had to run
git remote prune origin
to tidy up my repository, then ran git pull again.
Thanks also @mdma for your note about the Particle.variable() API changing, that saved me a bit of troubleshooting I’m sure!
1 Like
Threading is a wonderful new feature! No more blocking wireless connections! And combined with interrupts it does marvels. Thanks a lot for that! 
3 Likes
I have an issue with analogWrite on firmware 0.4.6. It looks as if the analogWrite function on DAC1 & 2 no longer works. I’ve used a simple loop writing to DAC1 $ 2 the values from 0 to 4095 and the output on both pins stays at 3.3V. If I run the same code on 0.4.5 (on the same device) I get a sawtooth signal as expected. Anything changed in analogWrite?
That’s quite surprising - nothing low-level apart from some changes to I2C were made in 0.4.6 (to my knowledge.) I’ve heard some mention that you have to set the pinMode before each dac output. Could you try that?
Did this. I have an application controlling fan speed via an analog output and that worked fine until the update. It also worked shortly after applying the update until I reapplied power to the device. I used a second photon with a very simple piece of code (loop from 0 to 4095, output to DAC1 & 2) and that showed the same issue after being updated to 0.4.6. After rolling back to 0.4.5 the simple test program worked again. To me this looks like some initialization of the device is different in 0.4.6 compared to the older firmware.