lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Dear Derp:

Thank you for your detailed explanation.

>Even for non-multithreaded programs, a common way to guarantee
>sandboxing without hijacking tables is to create a Lua State for each
>participant.

I can't fully understand it.
What is "sandboxing without hijacking tables'?
Could you please explain that more in detail for me or suggest some
documents for me to go through?

Thank you for your attention to my question.
Best regards
Sunshilong

On Wed, Oct 21, 2020 at 9:55 AM JeanHeyd Meneide
<phdofthehouse@gmail.com> wrote:
>
> Dear Sunshilong,
>
>      Each Lua state is entirely self-contained, and therefore you can
> make 10s or even 100s of them in one C/C++ process. The common way to
> do multithreading with Lua is to create multiple lua_State's, and then
> let them run independently while setting up ways to communicate
> information across threads in specific ways to need it.
>
>     Even for non-multithreaded programs, a common way to guarantee
> sandboxing without hijacking tables is to create a Lua State for each
> participant.
>
>      Note if you have 2 or more Lua States, you cannot use a reference
> (Table, Userdata, etc.) that came from Lua State #1 with Lua State #2
> without invoking undefined behavior (and, in severe cases, a crash).
>
> Hope that helps,
> Derp
>
> On Tue, Oct 20, 2020 at 9:50 PM 孙世龙 sunshilong <sunshilong369@gmail.com> wrote:
> >
> > HI, list
> >
> > Is there any circumstance that needs to invoke lua_newstate () to
> > create two or more Lua states in a single C\C++ process?
> > It would be better if you can give me a few simple examples.
> > What aspects should I consider(or be aware of) when creating two or
> > more Lua states in a single C\C++ process?
> >
> > Best regards
> > Sunshilong