Re: Lua State and callbacks from C

[Glenn Schmottlach <gschmottlach@...>]

>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?

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.

On Tue, Oct 9, 2012 at 4:46 PM, Thijs Schreijer <thijs@thijsschreijer.nl> wrote:

> On Behalf Of Glenn Schmottlach
> Sent: dinsdag 9 oktober 2012 18:34

>
> I have a question about providing Lua callbacks from a wrapped C
> library that seems to have never been fully answered (at least I can't
> find the thread). I am hoping someone can offer a recommended approach
> for this problem.
>
> In general, when I've wrapped 'C' libraries with Lua there are
> invariably callback functions that need to be handled as well. For the
> sake of this discussion I am assuming the 'C' callback is delivered on
> the same OS thread on which the main Lua state has been initialized in.

>From your Lua code you call into C code, which executes something and
returns a callback. As long as you do not touch the luastate, the garbage
collector will not have a chance to run. Though this is more theoretical as
I assume the callback delivers some result you need to push on the stack,
and that is the very moment you touch the lua state and then GC might run.
But then still, the L reference you got represents the current active thread
in the Lua state, which hasn't continued as the code (the OS thread) was
waiting for the callback to occur. I doubt, but have no certainty, that the
GC will ever collect the currently active thread, even if not anchored.
Maybe someone else can confirm this.

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.