Re: Manipulating a yielded thread from C

["Sam Roberts" <vieuxtech@...>]

On Mon, Dec 1, 2008 at 11:33 AM, Patrick Donnelly
<batrick.donnelly@gmail.com> wrote:
>> Looks legal to me, but I can see why you wonder. I don't see why you use the
>> thread lua_State instead of the parent lua_State.
>
> This is because the main lua_State thread is resuming threads and is
> not available to execute the callback function. I thought perhaps I

Now I'm confused again. We established you don't have OS threads.

So the main lua_state cannot be currently "resuming a thread" while
the C code you showed is running unless that C code was actually
called from that main lua state.

But in that case you would have L, the global state, available to you
and you could use it...

> would need to make a simple throwaway thread for running each callback
> function but was hoping to avoid that by just using the yielded
> thread.

I suspect there is a simpler way of doing what you are trying to do.
Is your code available somewhere?

I use nmap (my company actually has a license to it), and we use lua,
which is why I'm a bit interested in what happens with lua in nmap. It
might not be useful to us, but maybe it will be.

> There actually is no lua_pushthread (lua_State *, lua_State *) API
> function available (although I feel there should be). It seems I'll

True, but you don't need it. When you called lua_newthread(L) it left
a thread on L's stack (as well as returning you a lua_State* pointer).
Where did you store that thread object?

That object must be stored somewhere to prevent it being GCed, or the
thread pointer you have will mysteriously have its memory collected
sometime when the GC runs.

Anyhow, the thread object can be  copied from state to state with
lua_xmove(), or more likely just got from wherever you stored it. If
you store it in a table using a lightuserdata key you can get the
thread object given its C pointer value.

Sam