As the title says... Chat on...

User avatar
By j0hncc
#14721 Is there a mechanism for coordinating the code executed by alarms, triggers, and other events such as serving a webpage? That is, at some point one is reading from a sensor and storing it into an array, and it is in a partially-constructed state, other executing code needs to account for that.
So there needs to be at least some atomic test-and-set mechanism?
Or am I missing something.

Thanks,
John
User avatar
By TerryE
#14804 The simple answer is no because you don't need one. Once Lua starts executing it runs to completion but any global context is preserved. Any timer or triggers simply start another Lua execution sequence when they fire which is why you should not use poll loops or the like: If the "background" thread is still running then the "foreground" trigger will delay its firing.

A corollary is that you shouldn't use any inherited variables in your closures that you use as your trigger routines as these will create references which will frustrate garbage collection at the end of each execution sequence.
Last edited by TerryE on Fri Apr 17, 2015 10:12 am, edited 1 time in total.
User avatar
By j0hncc
#14823 Thank you for your reply.

"A corollary is that you should [? ] use any inherited variables in your closures that you use as your trigger routines as these will create references which will frustrate garbage collection at the end of each execution sequence."
(Should there be a "not" in there? )

I am a bit fuzzy on the application of that; I'm new with this Lua model. Could you elaborate on whether and how it applies to this example:
Code: Select alllastpulse_time=0
pulse_duration=0

function pulse_handler()
  local now = tmr.now()
  pulse_duration = ( now - lastpulse_time ) % math.huge
  lastpulse_time= now
end

E.g. are lastpulse_time and pulse_duration "inherited variables in my closure that I use as my trigger routine (pulse_handler)"?

Cheers,
John
User avatar
By TerryE
#14831 Joh, sorry you are correct the negative should be there -- I've updated my post. Inherited values or upvalues as the lua VM people call them create a reference from one routine to its parent routine and this can complicate its GC -- sometimes but not always.

The code block and function header for any routine is just a heap object in Lua just like a table or string. When no references to it exist any more then the GC can collect the RAM and return it to the heap. If you are running Lua on a PC, say, then this amount of memory is peanuts so forget this issue. However, on the ESP8166 where you only have just over 20K application RAM to work with, you have to understand how the GC system interacts with the VM and move through your code on a just-in-time basis, ensuring that you've fully dereferenced it when you've done.

Run your code through luac -l on your PC if you want to understand how this works.

In your case lastpulse_time and pulse_duration are globals and not inherited locals so there's no issue here.