[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Per-thread immutable variable
- From: Kriss <Kriss@...>
- Date: Wed, 10 Aug 2005 12:58:13 +0100
William Ahern wrote:
Personally I provided some management c functions to the thread with
upvalues related to the thread embedded in them, the thread can then
call these functions or throw them away but it cant call them pretending
to be another thread.
How would I go about creating a per-thread immutable table which is a
different C object for each thread? Do I add it to the globals for each
thread? Or, do I create an upvalue? in the thread? But, is it possible
to make an upvalue immutable?
Actually, to be more precise I want to create a sandbox for code which
runs in it's own thread (possibly creating more threads though not
necessary), and which has access to immutable C objects--so that Lua
code can't remove the object, which is necessary for underlying C code
to know the context of the thread.
Also, is the registry global across all threads created from the same
original Lua context?
Do you really need to sandbox threads? I'm asking because that was my
initial instinct and I moved away from it.
When I looked at the act of securing a sandbox I decided it just added
too much complexity/work/thinking. This obviously depends upon how much
access you need to give the thread and is the standard problem of
security vs usability. I just made it difficult to break some obvious
things by mistake and stopped thinking about making it impossible to
the determined. But you may really need that security.
Yup, the registry is global to the context and only accessible to the c
side, so hide stuff there.
If this helps at all I have two levels off objects/data, one level is
system wide, allocated on the c side not hooked into the garbage
collection but some access is provided to the lua side. The lua side can
decide to throw away its references but only the c side can decide to
actually free it, this level tends to be generators for the other level.
The other level is shared and hooked into the garbage collection, either
side can allocate it. If its allocated by the c side then lua has no way
of deleting it but if its allocated on the lua side then either lua or c
can cause it to be deleted. This means if the lua side allocates it the
c side must not cache pointers and only use lua to reference it but the
c side is still free to allocate its own do whatever it likes with it
and only provide lua with some access.
The not caching pointers is not strictly true, since the object can keep
itself in lists/whatever as long as it remembers to remove itself when
its deleted by the gc.
http://XIXs.com -><- http://www.WetGenes.com