@chap @bko We just deployed today the result of our spec’d github issue Controlling the Connection. Documentation forthcoming this week, probably tomorrow.
Wrote and then deleted a bunch of stuff because I misunderstood your issue…
Actually, mostly never mind there—I see you’re already using the workaround spark_disable_cloud.h. You no longer need that as of today. Use SYSTEM_MODE(SEMI_AUTOMATIC) instead. However, I see that’s not what you’re asking about.
OK, switching to more in-depth firmware explanation mode.
When you call Spark.connect(), all you’re doing is setting a flag. That returns immediately.
After your loop finishes, we go handle all the background Cloud stuff in SPARK_WLAN_Loop.
If you need to connect to Wi-Fi, we do so here, which calls WiFi.connect(). This is also really fast because it’s asynchronous, sending some messages to the CC3000 and returning. If the Wi-Fi module is not even on, then wlan_start can take some milliseconds, but basically you won’t notice this.
Now your code goes back to running.
Later, when the CC3000 successfully gets an IP address from the router, we get an asynchronous event, which sets some flags and turns the LED green.
Remember that SPARK_CLOUD_CONNECT flag we set a while back? Now, after your loop runs and we go back to the background stuff, we now actually get past this return statement and because WLAN_DHCP is set, we get to Spark_Connect() defined here.
After some quick initial work to read the server address off the external flash chip, we actually open up the TCP socket to the Spark Cloud here, with the call to connect (TI doxygen). As you can see in the code surrounding the connect call, we’ve implemented a watchdog that will kill the attempt to connect if it takes too long. Over in the core-common-lib repo, you can see this is set to 8 seconds. If you’re building locally, adjust as you see fit.
Assuming the TCP socket got opened successfully (potentially 7.99 seconds later, but obviously usually much faster), then we attempt the secure handshake with the Cloud in Spark_Handshake() defined here.
This is where we drop out to the core-communication-lib here to do some encryption and send a handful of messages back and forth, all of which must complete before we head back to your loop.
If you (and ten other capable people!) want to measure how long each of these steps takes, I’d be curious to hear your results. I suspect that the CC3000’s connect varies a great deal and is usually the longest blocking call. I suspect that the communication library handshake, including the encryption, is much more consistent. It would vary a bit due to internet connection speed, but we’re only sending two messages each direction (plus TCP ACKs of course), for a total of 698 payload bytes + IP and ethernet frames.
And if you have ideas for improvements, we are, as always, all ears. 
I hope this helps you understand all the states during which you could be receiving input, when your loop would be running, and when it will be blocked by other work. Cheers!