Oh, you have loop inside widget. I know it too, since I also have my mifi graph widget updated per second (with 600 ms script execution time). So if I activate the flow, there is only 400 ms left persecond to execute other flow. So I must make sure I don't have any critical flow running when I am using the graph widget.
Your problem still can be mitigated by moving the sleep outside. But first, it seems you are trying to implement the time format by yourself. Just use the automagic built-in dateformat to parse the date to the format you want. If you need to show the duration in
HH:mm:ss format, just use UTC timezone as the base, your time will always be correct. (You can find more about the date pattern at the script or you can check the direct link at my index).
Code: Select all
while (existsFile(global_external_storage_dir + "/call_state_ended") == false)
{
sleep(1000);
local_elapsed_seconds = getDate() - local_start_time;
local_time_format = "{local_elapsed_seconds,dateformat,timezone,UTC,HH:mm:ss}";
global_elapsed_time = local_time_format;
}
Then let's try to remove the sleep(1000) and put it outside of the script. You can start by putting the condition to check into another temporary variable. And then remove the sleep().
Code: Select all
check = existsFile(global_external_storage_dir + "/call_state_ended") == false;
while (check)
{
local_elapsed_seconds = getDate() - local_start_time;
local_time_format = "{local_elapsed_seconds,dateformat,timezone,UTC,HH:mm:ss}";
global_elapsed_time = local_time_format;
}
Add a new condition expression after this script, put
Yes, only
check, just like that. Since
check will always evaluated to true or false. True go to Action Sleep 1 second, false continue to the branch you need. The sleep 1 second loops back to the script. The reason why we put the condition to a temporary variable
check, is so we don't have to reevaluate again in the expression, making the script much-much shorter. (only
check)
At the beginning, you have 1 script only, and suffered from the global script lock forever.
In the end, you have 1 script, 1 expression and 1 action sleep which loopback to the script. You only suffer unnoticeable 4 ms script lock every seconds (since script usually takes around 4 ms to finish).
In Automagic EAP 1.35.0, you don't have to put the sleep outside. But it is still a good practice to separate out the sleep, especially when it is looped.
========================
Separate global lock
As for me, even though your problem is solved (hopefully), mine is not. If my widget update speed somehow require more than 1 seconds to complete, I will suffer from forever global script lock. I here then request a checkbox in the script, where we can exclude only that particular script from the global script lock. So that script will execute in parallel with another script in another flow. There will be a warning telling us that "we must have make sure that script is not modifying any glovar or doing any I/O or conflicting function to other flow". Another extra warning "enabling the separate global lock can cause chaos".
I am not sure if this is a good idea. But some of us probably have a forever running flow to update a widget info per seconds. If that script is always running, that means we have forever global lock. Since most likely that script only modify 1 widget only, I think is OK to include this "separate global lock" only for that script; of course as long as we have designed the flow properly. Maybe also add another extra option to list out any script which have this option enabled, so we can immediately check them when problems caused by this "separate global lock".