Lua restore issues - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: [1]   Go Down

Lua restore issues

  • 2 Replies
  • 3524 Views
*

Offline reyalp

  • ******
  • 14138
Lua restore issues
« on: 29 / November / 2013, 00:09:09 »
Advertisements
This is something that I've been ignoring for a long time, but waterwingz brought it up again so I'm posting to collect the issues.

restore() in lua can't call anything that yields. If it does, the function will effectively end when the yield is encountered. Related thread http://chdk.setepontos.com/index.php?topic=9467.msg97585#msg97585

The debug hook auto-yield may be hit while running restore. This should be easy to prevent using lua_script_disable_yield_hook, although in that case long running restore code could hang.

I'm pretty sure that restore code also sometimes triggers a Lua assert, but I wasn't able to reproduce this the last time I tried. Asserts are normally ignored in our hacked up Lua implementation, because there isn't really a sane response available, but this might cause memory corruption or other issues. OPT_DBG_LUA_ASSERT should cause them to be detected.

On somewhat related note, restore only runs if you interrupt the script with the keyboard. It would be desirable to be able to run something like this on runtime errors. In normal Lua environments, you'd do this using pcall / xpcall, but because these can't be used across a yield, this is impractical for top level error handling.

I'm not sure what a solution would be at this point. One possible approach might be run restore in a new lua thread, swapping Lt so it could still resume and yield.


Logged
Don't forget what the H stands for.
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: Lua restore issues
« Reply #1 on: 29 / November / 2013, 09:24:15 »
Quote from: reyalp on 29 / November / 2013, 00:09:09
restore() in lua can't call anything that yields. If it does, the function will effectively end when the yield is encountered. Related thread http://chdk.setepontos.com/index.php?topic=9467.msg97585#msg97585
My current work-around for this is use set_exit_key("no_key") to disable the exit key and then monitor for the full-press keystroke in my main program loop.   When the main loop sees the full press, it calls restore() and then exits the script. 

Of course, this only works well on a fully debugged script.  If the script gets "lost" somewhere then you need to resort to the power button / battery pull for reset.

Quote
One possible approach might be run restore in a new lua thread, swapping Lt so it could still resume and yield.
Would you still have the context of the original script at that point?  Some restore() functions may need to make decisions based on the state of some of the original program's variables.
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline reyalp

  • ******
  • 14138
Re: Lua restore issues
« Reply #2 on: 29 / November / 2013, 16:45:15 »
Quote from: waterwingz on 29 / November / 2013, 09:24:15
Quote
One possible approach might be run restore in a new lua thread, swapping Lt so it could still resume and yield.
Would you still have the context of the original script at that point?  Some restore() functions may need to make decisions based on the state of some of the original program's variables.
Globals are shared between threads, so it should be possible, but some existing scripts might not behave the same.

A little more background:
The interrupt key is detected when the running script is yielded at some arbitrary and unknown point, either by yielding call like sleep() or the debug hook.

The current code just calls the global function "restore", in the same thread as the main script (Lt in the code) It's not totally clear to me if this is even technically valid, since the thread is theoretically suspended.

Since it is called in a standalone call to lua_pcall, it doesn't have any way to resume if the underlying code yields. In fact, it's not clear to me that yielding in a pcall is valid either.

There isn't really a clear way to externally kill a thread either, although it should be cleaned up when lua_close is called on the main lua state. This raises another issue, since the GC methods are probably only called on lua_close, and these can't yield either.
Logged
Don't forget what the H stands for.
Pages: [1]   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal