Proper threading with lua_lock and lua_unlock

[Frityet]

What's the best/correct way to do threading when I define lua_lock and lua_unlock? Should each thread have its own coroutine state or a proper full lua state?

[Thijs Schreijer]

the way I understand it is that the VM is reentrant. So if you use separate "full lua states", 1 per thread, you won't need the locks.

Thijs

[bil til]

Am Mo., 3. März 2025 um 12:02 Uhr schrieb 'Thijs Schreijer' via lua-l
<lu...@googlegroups.com>:

> the way I understand it is that the VM is reentrant. So if you use separate "full lua states", 1 per thread, you won't need the locks.

Lua standard definition of lua_lock/unlock is just " ((void) 0)" - so
just "not used".

As I understand it, lua_lock/unlock just "just" help porting the
"reentrant"/"single VM" default scheme of Lua to non-reentrant
multithreading system which work by interrupting each other / running
on multiple cores.

(I anyway hate such systems, you then have to program very carefully,
better use different Lua machines in every thread I would propose).

[Viacheslav Usov]

On Mon, Mar 3, 2025 at 12:02 PM 'Thijs Schreijer' via lua-l
<lu...@googlegroups.com> wrote:

> the way I understand it is that the VM is reentrant. So if you use separate "full lua states", 1 per thread, you won't need the locks.

One thing to beware is libraries. Some of them are written in blissful
ignorance of multithreading. Frankly, I am unsure whether those
lua_lock things could fix that. A few times when I came across such a
problem, I ended up having to patch the library.

Cheers,
V.

[bil til]

Am Mo., 3. März 2025 um 16:36 Uhr schrieb Viacheslav Usov <via....@gmail.com>:
> lua_lock things could fix that. A few times when I came across such a
> problem, I ended up having to patch the library.

... so you applied Lua to a non entrant Multithreading system?

Just for curiosity, could you perhaps give some details?
(PC-Windows / PC-Linux/ other system?)
(Application target which required the non-reentrant multithreading approach?)

[Thijs Schreijer]

Your best best with libraries is to not use any local state in the library. Don't use malloc and free, but instead use Lua to allocate a userdata. That ensures the data lives inside the luaState and your library doesn't have to go though a bunch of hoops to be reentrant.
Obviously you can't always get away with that, and in those cases you have to ensure thread-safety in the library itself.

Thijs