My problem is : In most case, open sources projects uses the OS default Lua
library. This is useful because the task of OS maintainer is providing
libraries updates (fixing bug or security fail), and this is not the
task of the open source project maintainer.
Actually, the “lock interface” is defined using defines at compilation.
I guess this is for performances reason: it is useless to call function
or set a lock if multithread is not enabled. So, with this built-time
solution, the distribs cannot propose a package multithread-ready.
I propose myself to write a patch about multithread and lock, but first
I need your opinion. What do you think about integration of build-optional
"lock manager" for multithread usage of Lua ?
This seems match with requirements:
- No thread and performance requirement, build Lua without lock manager
- Thread and very specific integration, use your own lock with the actual
- Distribs packaging build with the manager, and each software using the
distrib lib can use the lock manager or no. The overhead is just a call
to empty function
The patch could be something like that (this is a very quick idea which
is not perfect):