[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: RE: c module, using static variables
- From: "Thijs Schreijer" <thijs@...>
- Date: Mon, 16 Apr 2012 19:16:26 +0200
> From: lua-l-bounces@lists.lua.org [mailto:lua-l-bounces@lists.lua.org]
> On Behalf Of Graham Wakefield
> Sent: maandag 16 april 2012 2:06
> To: Lua mailing list
> Subject: Re: c module, using static variables
>
> There is in 5.2, but not in 5.1, unless you dig into the internals (not
> portable).
> One workaround is to assume that the L used in your luaopen_xxx is the
> master state, and store it in the registry. But that still doesn't
> help you, since the registry isn't necessarily safe to access from a
> separate thread.
>
> Is there really no way to attach the structure to the callback itself?
> Most callback-oriented APIs allow the attachment of a userdata pointer
> to avoid using globals.
Having a sort of solution (at least that's what I think :) )
I'm giving each lua state a userdata (on the register) with its global data
(that is global data from my lib for that lua state), so as long as that is
firmly anchored I can access it safely from outside the lua state.
The code has to support multiple async libraries, so I now require each
library (when 'required' from Lua) to register themselves with my lib and
get a unique ID. L is included when it registers, so that enables me to link
the library IDs to the struct with the global data (in the userdata).
Now when my lib is called from lua, I can collect and access that global
data from the register and when called from the async lib (from the
background, without a valid safely accessible lua state), the unique ID can
be used to access the global data.
All the pointers, lua states, coroutines, threads, locks, safe and unsafe
handles, have made this into quite a mind bending exercise. But so far I'm
enjoying the ride :)
Any hints or tips on improving the above are most welcome.
Thijs