Re: Protecting upvalues / env via C API

[云风 Cloud Wu <cloudwu@...>]

Sherief Farouk <sherief.personal@gmail.com> 于2022年2月7日周一 00:32写道：
>
> I had the need to protect globals / environment from modification by
> code - not for security, merely for correctness and convenience, so
> not a proper sandbox, and I found this to be a common request judging
> by the amount of search results spanning over a decade, but no
> high-performance solutions existed AFAIK up till Lua 5.4
>
> I attempted a modification allowing an enable / disable bit for
> OP_SETTABUP controlled by a C API, and the overhead in my use case was
> negligible and it covered all the situations I'm interested in. A
> patch is attached.
>
> Is there interest in mainlining this feature? I wouldn't mind
> maintaining a local fork with this applied for my needs, but I think
> the widespread interest in this problem might make it viable. I am not
> sure, however, how this fits into the bigger picture with such a
> widely used library.
>
> Looking forward to some opinions.
>

I add a new C API to make any GCObject read only in my (lua 5.4) fork:
  https://github.com/ejoy/lua/tree/skynet54
The age of the object is between 0 (G_NEW) to 6 (G_TOUCHED2) in
official lua 5.4, and it uses 3 bits for the age. So I use age 7 for
readonly.

The readonly objects can't be modified by any OPCODE or C API, and
never be collected (It bypass the mark phase of GC).
It's very useful because the object can be created in another VM, for
example, you can create table/function in another thread or share
tables among multiple lua VMs.
It is also beneficial to GC if you have a lot of readonly data.

-- 
http://blog.codingnow.com