 |
lua-l archive |
|
|
||
|
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.
-- Kriss http://XIXs.com -><- http://www.WetGenes.com