version 0.5

[Akeit0]

reopen #135

[Akeit0]

since the underlying API is wrapped by LuaState and it doesn't usually show up in intellisense.

That doesn't seem correct.

Well, I think it's fine to create a new Lua thread every time. Using pooling might be more efficient, but in practice there are few situations where such optimization is necessary.

Are you implying that you do not want Rent~~ API?
Since LuaCoroutine has the ability to return the contents to the pool when it becomes Dead, we need an API that uses the pool so that we can use it (ThreadCoreData).

Since it is up to the user to use the Rent* api (a wrapper for Create in the first place), is there any reason to remove it?

LuaThreads can use large amounts of memory, so there is a necessity to use pools.

[nuskey8]

That doesn't seem correct.

What's not right? In the current implementation, LuaState is essentially a wrapper around LuaMainThread, and the addition of ResumeAsync to it has no effect on the LuaState API.

Since it is up to the user to use the Rent* api (a wrapper for Create in the first place), is there any reason to remove it?

Too many options for users can confuse them. It would be better to add something like LuaThreadSource that holds internal data such as, and implement LuaThread as a wrapper around it.

[Akeit0]

What's not right? In the current implementation, LuaState is essentially a wrapper around LuaMainThread, and the addition of ResumeAsync to it has no effect on the LuaState API.

I meant that when we use CreateThread, we can call Resume from it.

Too many options for users can confuse them. It would be better to add something like LuaThreadSource that holds internal data such as, and implement LuaThread as a wrapper around it.

Can you provide an approximate structure and APIs?

[nuskey8]

I meant that when we use CreateThread, we can call Resume from it.

C-Lua allows resuming threads created with lua_newthread, so we should support this too.

Can you provide an approximate structure and APIs?

The API I propose is as follows.

// Here, it is called state, but it needs to be possible to create it from any Lua thread
var thread = state.CreateThread();
try
{
    // You can use the same API as LuaState
    var results = await thread.DoStringAsync("foo()");
    Console.WriteLine(results[0]);
}
finally
{
    thread.Dispose();
}

As for the internal implementation, there should be no problem if we use the current LuaCoroutine.

Currently, the implementation of LuaState and Lua threads are separated, but it may be good to integrate them like C-Lua.

[Akeit0]

If we integrate LuaState and LuaThread, can I add LuaGlobalState to replace current LuaState?

[nuskey8]

Is LuaGlobalState necessary? Why can't we just have LuaState?

[Akeit0]

The reason is simply that we need a type to store information that is unique to current LuaState, such as platform, registry, packages, and so on.

[nuskey8]

Wouldn't this be possible by creating a global state for LuaState to hold and sharing the same instance?

Below is example code. The class names are merely examples and more appropriate names would be needed.

class LuaState
{
    readonly GlobalState global;
    ...
}

class GlobalState
{
    LuaPlatform platform;
    LuaTable registry;
    LuaTable environment;
}

[Akeit0]

In that form, would it be the almost same API split as LuaState/LuaThread?

[nuskey8]

Well, that's certainly true. I guess we need LuaState and LuaThread after all.

[juliolitwin]

Has this branch/version and project been abandoned, since the project owner is now working on another bindings project?

[nuskey8]

Although development has slowed (due to my lack of involvement in maintenance, sorry), I still recognize the importance of Lua-CSharp. Although v0.5 has not yet reached release status, we will continue to develop it.