Lua functions and other language details

msl

1280
A720 IS, SX220 HS 1.01a

Re: Lua functions and other language details

« Reply #10 on: 09 / April / 2013, 13:28:41 »

Advertisements

Quote from: Microfunguy on 09 / April / 2013, 08:04:22

Quote from: waterwingz on 08 / April / 2013, 23:43:04
Something tells me Lua is not going to end up in SDM any time soon.

It will NEVER be supported by SDM, why should it ?
We are just taking photos, not testing elegant programming techniques for the benefit of developers.
If a user really needs Lua (which is difficult to believe) just use CHDK.

In fact, I have suggested to someone that the new SDM installer should download SDM and CHDK, the CHDK DISKBOOT file having its extension temporarily changed.

This is not the topic of this thread!!!

Thanks goes to reyalp for your very interesting informations.

msl

Logged

CHDK-DE: CHDK-DE links

philmoz

3450

Re: Lua functions and other language details

« Reply #11 on: 09 / April / 2013, 19:11:44 »

Question - why does 'lua_script_start' create a new Lua thread/state (Lt), and run the script on that thread instead of just using the main thread/state created by lua_open (L)?

Sample code I found with Google only seems to use the main thread.

I tried removing 'Lt' and just using 'L' and it all still seems to work - I'm sure there is a reason for it, just curious as to what it is.

Phil.

Logged

CHDK ports:
sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
g12 (1.00c, 1.00e, 1.00f & 1.00g)
sx130is (1.01d & 1.01f)
ixus310hs (1.00a & 1.01a)
sx40hs (1.00d, 1.00g & 1.00i)
g1x (1.00e, 1.00f & 1.00g)
g5x (1.00c, 1.01a, 1.01b)
g7x2 (1.01a, 1.01b, 1.10b)

lapser

1093

Re: Lua functions and other language details

« Reply #12 on: 09 / April / 2013, 20:01:32 »

Quote from: philmoz on 09 / April / 2013, 19:11:44

I tried removing 'Lt' and just using 'L' and it all still seems to work - I'm sure there is a reason for it, just curious as to what it is.

That's interesting. I tried changing it like this:

// Lt = lua_newthread( L );
Lt = L ; //testing

My script works with the change, so I think I'll do another lua yield bug test with this version. It seems like it would add a lot of unnecessary complexity to have 2 lua threads running in one task.

Digging into lua_newthread(), it seems to reserve another lua stack, so it would be more memory efficient with one thread. I also discovered where they set the lua stack size in lua.h so I'll try doubling it for my bug test.

/* minimum Lua stack available to a C function */
//#define LUA_MINSTACK 20
#define LUA_MINSTACK 40

[EDIT] I noticed that Lt is used for pushing values returned to Lua from C functions, and L is used for other things. I think the reason for the extra thread is to get more stack space for C functions called by Lua. But it looks like changing LUA_MINSTACK does the same thing more efficiently. Considering this, I think I'll up the stack size to 80 for the test.

[EDIT2]ptpcamGUI connects but fails to INIT with this version. Maybe the extra lua thread is for PTP?

« Last Edit: 09 / April / 2013, 20:28:40 by lapser »

Logged

EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

reyalp

14080

Re: Lua functions and other language details

« Reply #13 on: 09 / April / 2013, 21:55:37 »

Quote from: lapser on 09 / April / 2013, 20:01:32

It seems like it would add a lot of unnecessary complexity to have 2 lua threads running in one task.

There aren't actually two threads running.

Logged

Don't forget what the H stands for.

reyalp

14080

Re: Lua functions and other language details

« Reply #14 on: 09 / April / 2013, 22:16:20 »

Quote from: philmoz on 09 / April / 2013, 19:11:44

Question - why does 'lua_script_start' create a new Lua thread/state (Lt), and run the script on that thread instead of just using the main thread/state created by lua_open (L)?

I don't know for sure, but I would guess it's because the lua_resume documentation suggests that you need to create a thread first: http://www.lua.org/manual/5.1/manual.html#lua_newthread

To expand on my previous reply, everything happens in Lt, so the "other thread" really isn't doing anything, or adding significant complexity or resource usage.

These posts
http://lua-users.org/lists/lua-l/2012-02/msg00078.html
http://lua-users.org/lists/lua-l/2004-03/msg00007.html (note this is quite old!)
suggests that it would be OK to just use the main thread. I didn't find any detailed discussion with a quick search.

Also be careful with your "L". The global L refers to the original global lua state, but the L parameter in the functions must generally refer to Lt.

Logged

Don't forget what the H stands for.

philmoz

3450

Re: Lua functions and other language details

« Reply #15 on: 09 / April / 2013, 22:26:48 »

Quote from: reyalp on 09 / April / 2013, 22:16:20

Quote from: philmoz on 09 / April / 2013, 19:11:44
Question - why does 'lua_script_start' create a new Lua thread/state (Lt), and run the script on that thread instead of just using the main thread/state created by lua_open (L)?
I don't know for sure, but I would guess it's because the lua_resume documentation suggests that you need to create a thread first: http://www.lua.org/manual/5.1/manual.html#lua_newthread

To expand on my previous reply, everything happens in Lt, so the "other thread" really isn't doing anything, or adding significant complexity or resource usage.

These posts
http://lua-users.org/lists/lua-l/2012-02/msg00078.html
http://lua-users.org/lists/lua-l/2004-03/msg00007.html (note this is quite old!)
suggests that it would be OK to just use the main thread. I didn't find any detailed discussion with a quick search.

Also be careful with your "L". The global L refers to the original global lua state, but the L parameter in the functions must generally refer to Lt.

I'd read through some of that documentation and this statment
Threads are subject to garbage collection, like any Lua object.
got me to wondering if the garbage collector was somehow 'collecting' Lt and returning it's memory to the heap.
This might explain the wierd behaviour and values being seen.

All of which led me to wonder why we need Lt in the first place - seems like it may not be needed.

Phil.

Logged

CHDK ports:
sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
g12 (1.00c, 1.00e, 1.00f & 1.00g)
sx130is (1.01d & 1.01f)
ixus310hs (1.00a & 1.01a)
sx40hs (1.00d, 1.00g & 1.00i)
g1x (1.00e, 1.00f & 1.00g)
g5x (1.00c, 1.01a, 1.01b)
g7x2 (1.01a, 1.01b, 1.10b)

reyalp

14080

Re: Lua functions and other language details

« Reply #16 on: 09 / April / 2013, 22:40:21 »

Quote from: philmoz on 09 / April / 2013, 22:26:48

All of which led me to wonder why we need Lt in the first place - seems like it may not be needed.

It would have to be very broken indeed to collect an active (running / suspended) thread.

Logged

Don't forget what the H stands for.

philmoz

3450

Re: Lua functions and other language details

« Reply #17 on: 09 / April / 2013, 23:01:09 »

Quote from: reyalp on 09 / April / 2013, 22:40:21

Quote from: philmoz on 09 / April / 2013, 22:26:48
All of which led me to wonder why we need Lt in the first place - seems like it may not be needed.
It would have to be very broken indeed to collect an active (running / suspended) thread.

I don't fully understand this discussion:
http://lua.2524044.n2.nabble.com/How-to-stop-yielded-threads-from-being-garbage-collected-td7026468.html
but it seems to be saying that a yielded thread can be garbage collected if there is no reference to it.

Is it possible the lua_script_start code is not properly saving a reference to Lt?

Phil.

Logged

CHDK ports:
sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
g12 (1.00c, 1.00e, 1.00f & 1.00g)
sx130is (1.01d & 1.01f)
ixus310hs (1.00a & 1.01a)
sx40hs (1.00d, 1.00g & 1.00i)
g1x (1.00e, 1.00f & 1.00g)
g5x (1.00c, 1.01a, 1.01b)
g7x2 (1.01a, 1.01b, 1.10b)

reyalp

14080

Re: Lua functions and other language details

« Reply #18 on: 09 / April / 2013, 23:13:37 »

Quote from: philmoz on 09 / April / 2013, 23:01:09

Is it possible the lua_script_start code is not properly saving a reference to Lt?

It's is stored in the "registry" which should keep a reference. Also, per that post if you were having this problem, it should give the mentioned error, not just die with a corrupt lua state.

I *really* don't think this is the issue, since you can force a full garbage collection and not have it die. Either the thread would be correctly referenced or not, it's not going to randomly stop being referenced after a thousand gc cycles.

Logged

Don't forget what the H stands for.