Page 1 of 1
Using non blocking wait
Posted: Sun Nov 22, 2015 7:55 pm
by kolia
Hello,
I have a handler "updateStatus" that runs every 10 seconds. At the very beginning of this handler we have
and at the end
User may click on any interface control at any time. At the beginning of the control handler, we have to make sure that updateStatus is not running in order to avoid concurrent calls to a hardware device. I have this instruction :
Code: Select all
wait while getUpdateStatusRunning() is true with messages
Can anyone tell me that it does what I'm expecting, that is the control handler will resume execution when the updateStatus handler hits the end, in order to avoid possible concurrent calls?
Thank you
Just for reference the code of the two routines
Code: Select all
local updateStatusRunning
command setUpdateStatusRunning pValue
put pValue into updateStatusRunning
end setUpdateStatusRunning
function getUpdateStatusRunning
if updateStatusRunning is empty then put false into updateStatusRunning
return updateStatusRunning
end getUpdateStatusRunning
Re: Using wait
Posted: Mon Nov 23, 2015 4:49 am
by dunbarx
Hi.
It is hard to comment, because, for example, you do not say what or where the handler "setUpdateIsRunning" is, or what it does. If I tried to reconstruct the handful of code smippets you mentioned, I would get a runtime error. There is no such handler, and I cannot go any further.
Perhaps come back with complete handlers? I hope they are not too long. I generally do not read long handler submissions, unless I can extract the salient portions or rewrite them into shorter examples.
Craig Newman
Re: Using wait
Posted: Thu Nov 26, 2015 10:48 am
by kolia
Hi Craig,
Thanks for getting involved in my question. I'll try to be as concise as possible.
updateStatus runs every 10 sec. At the beginning of the routine it sets a flag (setUpdateStatusRunning true) and at the end it sets the same flag to false (setUpdateStatusRunning false)
Whenever a user click, at the beginning of the handler the status of the flag is checked and the handler is paused (non blocking) until the flag is set to false by updateStatus. The instruction at the beginning this handler is:
Code: Select all
wait while getUpdateStatusRunning() is true with messages.
Both handlers, updateStatus and onMouseUp, access a remote hardware device and I wan't to avoid concurrent accesses. So I wan't to make sure that "wait while getUpdateStatusRunning() is true with messages" will pause onMouseUp until updateStatus reaches the end.
Nicolas
Re: Using non blocking wait
Posted: Thu Nov 26, 2015 2:56 pm
by WaltBrown
What is the difference between "setUpdateStatusRunning" and "setUpdateIsRunning"? You gave the code for the former but not the latter. Typo?
Walt
Re: Using non blocking wait
Posted: Thu Nov 26, 2015 7:43 pm
by zaxos
Code: Select all
wait while getUpdateStatusRunning() is true with messages.
No need for that, instead:
e.x. Code of button 1
Code: Select all
global isRunning
on mouseUp
if isRunning then
doSomething
else
-- do nothing
end if
end mouseUp
Code in stack
Code: Select all
global isRunning
on updateStatus
put true into isRunning
do stuff
do stuff
do stuff
do stuff
put false into isRunning
send isRunning to me in 10 sec
end updateStatus
You can use custom properties instead of a global, you can actualy have all the scripts in the card, but you get the big picture.
Re: Using non blocking wait
Posted: Sat Nov 28, 2015 9:53 am
by kolia
WaltBrown wrote:What is the difference between "setUpdateStatusRunning" and "setUpdateIsRunning"? You gave the code for the former but not the latter. Typo?
Walt
Yes sorry typo error the routine is setUpdateStatusRunning
Re: Using non blocking wait
Posted: Sat Nov 28, 2015 10:39 am
by kolia
Thanks Xanos for your contribution. But this is not the idea. The idea is to have the onMouseUp handler resuming execution when the updateStatus reaches the end.
Re: Using non blocking wait
Posted: Sat Nov 28, 2015 11:44 am
by bn
Hi Nicolas,
as far as I see when you run your "update" handler there is no way for another message to get processed since you don't e.g. wait with messages in that handler.
In theory you should not even have to check if the update handler runs because once it runs it blocks all other requests. Once the update handler is finished mouseUp should fire because it should be queued.
Unless your "update" handler is non-blocking
I made a little stack that simulates both situations.
On top 3 buttons. Click "simulate non blocking update" (runs 5 seconds) then "my MouseUp" repeatedly, in the field you will see the status of the simulate handler with the milliseconds attached to see something is going on.
myMouseUp2 button has a handler that checks the status of the non-blocking button and only proceeds when the non-blocking buttonn is done.
at the bottom 2 buttons for a blocking update handler
click "simulate blocking update" button (the button just waits for 5 seconds) and then click the myMouseUP3 button. The button does not react but the action is queued. Once the blocking handler is done you see the milliseconds change in the field.
By the way when checking the non-blocking handler with button myMouseUp2 I first tried to use "wait 1 second with messages" in a repeat loop: That did not work, apparently the non-blocking handler, which also waited with messages then never ended waiting. I had to use "send in time" to do this.
Kind regards
Bernd
Re: Using non blocking wait
Posted: Sat Nov 28, 2015 4:20 pm
by kolia
Hi Bernd
I really appreciate your valuable input. It explains another behavior I noticed without being able to understand it. This makes very clear how LC handles interruption if I may say so. I will check the stack you attached as soon as I can and I will post what I understood.
Thanks again
Nicolas
Re: Using non blocking wait
Posted: Sat Nov 28, 2015 7:21 pm
by FourthWorld
Only peripherally related, but this modest demonstration stack shows a couple ways to simulate some limited forms of threading in LC:
http://fourthworld.net/channels/lc/IdleHour.rev
Re: Using non blocking wait
Posted: Sun Nov 29, 2015 12:13 am
by kolia
Thanks Richard, I'll look at this one as well