[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: recognizing whether a caller uses function result
- From: bil til <biltil52@...>
- Date: Thu, 23 Feb 2023 09:22:38 +0100
> 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)... .