lua-users home
lua-l archive

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


>   So you share a single Lua state among multiple operating system level
> threads?  Or are you talking about Lua coroutines?  The former (operating
> system threads, like pthreads under Linux) sharing a single Lua state
> require the implementation of lua_lock() and lua_unlock().

I am talking of cooperative multithreading "inside Lua" (so Lua
coroutines - just wrapped as my own "tasks" - I think my task library
is quite a bit more easily to handle by user than the Lua coroutine
scheme).

I do this on a single core embedded STM32 controller with very
restricted RAM. (for e. g. bluetooth this effectively uses a 2-core
system, but with very clear state driven data exchange / no
"concurrent RAM space" data handling which requires semaphore
handling...).

If you want to support CPU pre-emptive multithreading / hardware
multithreading on several cores e. g. of typical modern Intel PC CPU,
then you would need semaphore handling usually to ensure data
integrity ... . This I complicated and I would usually NOT recommend
to present such "data ambiguity problems" to a Lua user, but handle
this semaphore stuff then exclusively in my C code.

For Lua user in such case I anyway would strongly recommend to keep
with cooperative multihreading on Lua side (and effectively hide the
difficulities of the pre-emptive data handling from the Lua user /
manage the pre-emptive data and thread handling exclusively in my C
"task-library" code)... .