[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: RE: Lua State and callbacks from C
- From: "Thijs Schreijer" <thijs@...>
- Date: Wed, 10 Oct 2012 09:21:11 +0200
> On Behalf Of Glenn Schmottlach
> Sent: woensdag 10 oktober 2012 0:33
>
> >Continuing the line of thought; if it could GC the active thread, then
> >EVERY piece of C code MUST always have its first statement anchor the
> >thread because it might be collected (which would be silly). So my
> >logical conclusion is that my statement above must be right.
>
> That's not what I'm saying nor what I intended to ask. Of course as you
> enter the 'C' function that registers the Lua callback routine the Lua
> state (L) is referenced since this is the active context in which
> you're running.
>
> What I'm concerned about is after the 'C' registration routine returns
> to Lua but *before* any callback has been executed. Let's suppose we
> have an GUI main-loop running in the "main" Lua state/thread. It
> periodically calls a message dispatch function. In between calls to
> "dispatch" it creates a coroutine and resumes it. This coroutine does
> nothing more than registers a callback as I described. Once the
> registration function returns to Lua the coroutine exits and program
> flow continues on the main Lua thread. At this point time no callback
> has been issued (yet) since it can only be executed from the GUI
> "dispatch" function) but the coroutine (e.g. Lua thread) that called
> the callback registration function has exited. For this example let's
> assume my code *did not* anchor the coroutine Lua state in the callback
> registration function but merely copied the Lua thread pointer (L*). At
> the same time the GC has already collected the coroutine (since no one
> references it in Lua). When the "dispatch" function is called by the
> active (main) Lua thread, what Lua thread/state will my 'C' callback
> function use to call into Lua? I have what must be a Lua State pointer
> but I'm not sure on which thread my Lua callback will run. Will this
> run on the only Lua thread that is still active (e.g. the "main" thread
> associated with the Lua state)? Will my code blow up because when I
> copied the "L" pointer the active thread was the coroutine which
> doesn't exist anymore?
>
> If I anchor the Lua state/thread in my 'C' registration function will
> this prevent my coroutine thread from being garbage collected until
> *after* I've called into Lua and released the anchor?
No definitive answer (from me at least) but my guess would be that that
wouldn't work as the co-routine might have finished (the initial function
used to create it returned). Probably an error trying to resume a finished
coroutine or something similar. But that would be something easy to test.
What remains;
For 5.2 collect the mainthread and execute on that one, for 5.1 assume the
thread initializing the library to be the mainthread.
>
> Lua state/thread lifetime seems a little vague in this context. I think
> the difficulty lies in the fact that "L" combines them both and you can
> separately reference them.
>
Main questions are then (all from c code perspective);
1) can you execute on a lua state which co-routine has ended (access
of/execute on the execution stack element of that lua state)
2) can you access the lua state even if its associated co-routine has ended
(access the environment element of that lua state)
And even if these do work in a simple test, is it considered safe to do so.