Re: Question regarding the XML parser binding in PIL

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

On Fri, Nov 21, 2008 at 9:01 AM, Florian Weimer <fw@deneb.enyo.de> wrote:
> * Sam Roberts:
>
>>> The C callbacks use this L as the Lua state for C-to-Lua calls.  I can
>>> see that this works if the XML parser object is only accessed through
>>> Lua (before every callback, L is properly initialized).  In a similar
>>
>> What do you mean by only accessed through lua? These callbacks are
>> registered into a lua_State (valid, of course), so how could they be
>> called without that state, L, being properly initialized L?
>
> Suppose the XML parser object is passed to some other library which
> uses it some time later, in response to a different call (possibly
> from Lua code).  This would trigger the callbacks without a call to

That call was made from lua code. So it has a lua_State pointer, L...

> lxp_parse on the callstack, which means that the L pointer could be
> invalid.

which it would pass to lxp_parse.

There are two kinds of states, L, though this isn't totally obvious
from the C type (lua_State*). The "master" one (from lua_newstate),
and the "slave" ones (lua_newthread). threads know about their master
state, and use it.

Specifically, they use it to manage garbage collection, and userdata
allocation/collection. See:

  http://www.lua.org/manual/5.1/manual.html#lua_newthread

I.e., the userdata was created with an L. It KNOWS that it was created
with that L, and is forever bound to that L, and can only be used with
it (or thread created from that L via newthread, etc.).

The assignment that you are concerned about just allows your C code to
be able to figure out in C callbacks made from expat which state it
was created from. There are other ways to do this, but they aren't
usually as clean, would probably interact through a shared global-in-C
data structure, and none of them relax the restriction that a userdata
is tied to a lua_State.

Cheers,
Sam