Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Fixes Particle.connect() behavior in SEMI_AUTOMATIC mode #1403
Instead of blocking
Steps to Test
I'm still not sure why we need to block after a
Especially when using
If anything then
One point that would be useful tho' would be a guard against multiple calls of
If this is a non-issue for multi-threaded mode just the better, but still I can't quite see the rationale for this
I might misinterpret the part: "until the device connects", but when I interpret it as "until the device has connected", then I see some risk but no advantage in this.
Given a setting where
I know this fits to the (currently) documented behaviour of SEMI_AUTOMATIC mode, but I still don't see the benefit and rather think this is due to legacy before the advent of SYSTEM_THREAD and options like
Sorry for being awkward
Update: (no dementia)
So it appears that at first the docs were wrong but the behaviour was as most people would have liked it (despite the erronous docs) and now we are about to make the system fit the docs rather than the other way round.
The original spec for AUTOMATIC, SEMI_AUTOMATIC and MANUAL is here:
Particle.connect() in SEMI_AUTOMATIC and SINGLE-THREADED mode was always designed to be a blocking call.
Now that we have MULTI-THREADED mode, can we not just use that for unblocking things and let SINGLE-THREADED mode be mostly blocking as it was originally intended to be?
Here are some thoughts, it's not as simple as just running loop() because loop() is most important. In the single-threaded world, If we are supposed to be connected to the Cloud, and are not yet, that Cloud connection needs to be established and there is work to be done. Wi-Fi must be connected, and the Cloud handshake needs to occur. After that we maintain a heartbeat every ~15s but also process any incoming/outgoing messages every time loop() ends. If we go off and run loop() before those initial things happen, we could be taking a very long time to connect to the Cloud depending on what's happening in loop(). This is however the entire reason for multi-threaded mode, so loop() can run while all of those background activities are blocking and doing their thing.
Thanks Brett, for the additional thoughts
This whole discussion might be only academic once multi-threading will come out of beta and virtually becomes standard mode. However if this is the way to go, some definitive statement about the expected blocking periode (especially when not already WiFi connected) and possibly some means to change that timeout periode would be needed IMO (since such things as
For the users point of view
BTW, if a major factor in the rationale for making it blocking is that user code supposedly might do stuff that potentially interferes with the ongoing connection process, why not just call out that risk in the docs and hand back the responsibility not to do such things to the user?
And about the part "WiFi must be connected", why is then
I'm sorry but I don't have the answers you seek at this time. I agree more needs to be documented. There's also MANUAL mode as well in SINGLE-THREADED operation. This is the one you want if you want to emulate a slow MULTI-THREADED operation.
SEMI_AUTOMATIC is meant to just allow you to do some things in setup() before the connection process takes place, after which Particle.connect() essentially turns it into AUTOMATIC mode.
Can you show me some code that you rely on Particle.connect() not to block in SEMI_AUTOMATIC / SINGLE-THREADED mode?
(@technobly) Brett, it's not really that some of my code relies on the non-blocking behaviour as I do know my way around most the issues, but I'm rather playing advocate for a different school of thought (although I maybe shouldn't
The reason for the whole discussion was the "long standing (Oct. 2014 till 0.6.1-rc.1)" - so called - bug which "suddenly" got "fixed" causing users to get puzzled why good working code (despite the fact it neglected the docs, but was backed by semi-official "afaict"-statements) stopped working.
I've tested in order to confirm that when SYSTEM_THREAD(ENABLED) is set Particle.connect does not block in multi-threading mode. I also see now:
"We are only fixing semi automatic from not blocking loop when called in SINGLE--THREADED mode."
This does seem to be implemented the way i'd expect to deleting my previous rant :)