Device-os: Particle.connect() hard blocking since 0.6.1-rc.1

[ScruffR]

As discussed in this post the behaviour of Particle.connect() has changed with 0.6.1-rc.1 to completely block in non-AUTOMATIC modes without SYSTEM_THREAD(ENABLED).
Before Particle.connect() just set a flag and then left to continue running user code (considerably impacted by "background" tasks, but running).
Now the code following Particle.connect() does not get executed at all till the connection is established.

I'd consider this a silently breaking change, since the new "misbehaviour" only hits under certain conditions.

SYSTEM_MODE(SEMI_AUTOMATIC);

void setup() 
{
    pinMode(D7, OUTPUT);
    Particle.connect();

    while(1)
    {
      digitalWrite(D7, !digitalRead(D7));
      delay(100);
    }
}

Above code does immediately flash the LED on bootup and occasionally during connection attempts pre 0.6.1-rc.1 but with 0.6.1-rc.1 starting it never blinks till the connection has been established.
See desired behaviour with 0.6.0 https://youtu.be/YWVmkq3Z-mI

[technobly]

I believe this was a bug that was fixed.

See docs for expected behavior: https://docs.particle.io/reference/firmware/electron/#semi-automatic-mode

Original issue:
https://github.com/spark/firmware/issues/973

[ScruffR]

Hmm, I'd rather go with Mat's first inclination that the original behaviour is not a bug and the use of waitUntil()/waitFor() would help the issue better.

But since it's documented I guess I have to accept the decision 😖

[technobly]

Is there some reason you cannot use SYSTEM_THREAD(ENABLED); along with or without waitUntil() / waitFor() to get the use case you desire? Please close the issue if you feel it is sufficiently resolved, thanks!

[ScruffR]

No real reason, but a sight feeling that there is no perfect solution either way.

[m-mcgowan]

I am re-opening this since the PR that was referenced above needs reworking slightly to align with the expected behaviour as described in the docs, namely that Particle.connect() does not block and that the blocking happens next time setup(), loop() are called. Open question is if this should be extended to delay() also.

[elcojacobs]

I'd like to add a note to this issue that in my tests with RC-6 and SYSTEM_THREAD(ENABLED) WiFi.connect() is BLOCKING!

This means that if WiFi goes down, it completely stops my application and the photon spends all of its time trying to reconnect to WiFi. All temperature control stops and my customer's beer is in danger of being ruined!

How do I get the old behavior back of actually handling this in the system thread?

[elcojacobs]

Upon further investigation, it seems that WiFi.connect() is not blocking directly, but it blocks execution of loop() while WiFi is connecting (with system thread enabled).

Could that be explained by how it is implemented currently and is there a workaround?

[aeris-ming]

@elcojacobs I have the same issue.When the internet connect is not stable or wifi signal is weak,the user thread will block forever.Have you find any way to solve this problem?

[aeris-ming]

@ScruffR @m-mcgowan @technobly If any of your guys find a solution of this issue.Please Please tell me,Thanks very much! WIFI connection is not so important for me compare to keep device run stable,Please!

[technobly]

@elcojacobs @aeris-ming This thread is for Particle.connect(), not WiFi.connect(), so I wonder if you have identified something different. If you have the ability to compile locally, would you see if this PR (slated for 0.7.0-rc.7) fixes your issue? https://github.com/particle-iot/firmware/pull/1403

[aeris-ming]

@elcojacobs https://github.com/particle-iot/firmware/issues/1486
https://github.com/particle-iot/firmware/issues/1449 Do you have any idea why user loop blocked when wifi signal is weak?I have report these issue months ago.

[aeris-ming]

@elcojacobs https://github.com/particle-iot/firmware/issues/1407 If you have any idea to fix this issue,Please tell me,Thanks!

[aeris-ming]

@elcojacobs
Can you search your project user part to see if your have call any sync-system-function?
They may block forever.
@m-mcgowan Help me find out my mistake, I called the sync-system-function hasCredentials() which may block forever.
https://docs.particle.io/reference/firmware/photon/#system-functions

[ScruffR]

Another (potential) instance where users might not anticipate the side-effect of blocking Particle.connect() in SYSTEM_THREAD(ENABLED) mode.
https://community.particle.io/t/particle-threads-tutorial/41362/7?u=scruffr

[jasongarner]

https://community.particle.io/t/particle-connect-timeout-retrydelay/41506

[technobly]

Another (potential) instance where users might not anticipate the side-effect of blocking Particle.connect() in SYSTEM_THREAD(ENABLED) mode.

I ran into this myself yesterday :(

We need to spend some time creating an easy to digest chart of system modes, threaded, non-threaded, with what blocks and what doesn't.

In my opinion loop() should always run in a threaded app.