Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Particle.connect() hard blocking since 0.6.1-rc.1 #1399

Open
ScruffR opened this issue Sep 27, 2017 · 16 comments

Comments

@ScruffR
Copy link
Contributor

commented Sep 27, 2017

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

This comment has been minimized.

Copy link
Member

commented Sep 27, 2017

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:
#973

@ScruffR

This comment has been minimized.

Copy link
Contributor Author

commented Sep 27, 2017

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

This comment has been minimized.

Copy link
Member

commented Sep 27, 2017

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

This comment has been minimized.

Copy link
Contributor Author

commented Sep 28, 2017

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

@ScruffR ScruffR closed this Sep 28, 2017

@m-mcgowan m-mcgowan reopened this Sep 28, 2017

@m-mcgowan

This comment has been minimized.

Copy link
Contributor

commented Sep 28, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Dec 28, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Jan 4, 2018

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

This comment has been minimized.

Copy link

commented Jan 30, 2018

@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

This comment has been minimized.

Copy link

commented Jan 30, 2018

@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

This comment has been minimized.

Copy link
Member

commented Jan 30, 2018

@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? #1403

@aeris-ming

This comment has been minimized.

Copy link

commented Mar 7, 2018

@elcojacobs #1486
#1449 Do you have any idea why user loop blocked when wifi signal is weak?I have report these issue months ago.

@aeris-ming

This comment has been minimized.

Copy link

commented Mar 7, 2018

@elcojacobs #1407 If you have any idea to fix this issue,Please tell me,Thanks!

@aeris-ming

This comment has been minimized.

Copy link

commented Mar 19, 2018

@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

This comment has been minimized.

Copy link
Contributor Author

commented Apr 28, 2018

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

@technobly

This comment has been minimized.

Copy link
Member

commented Jul 26, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.