Re: Why are lua_lock() and all macros?

[Tuomo Valkonen <tuomov@...>]

On Mon, Apr 14, 2003 at 10:02:56AM -0300, Roberto Ierusalimschy wrote:
> Overhead. To call a funtion (or simply check its existence) in every
> entry/exit to a Lua function is a waste for the majority of programs
> that do not need it.

I started thinking about this and got an idea for an alternative
thread support implementation that would need very little support
from Lua itself. What I propose is that thread-safe libraries handle
unlocking (usually after the data has been fetched from the Lua stack)
and locking (after the actual C function has been called and we're
ready to push return values and return to Lua) using some standardized
method. This would also provide required locking for bindings to
thread-unsafe libraries and the number of calls lua_lock/lua_unlock
should be reduced significantly. I think this requirement of libraries
handling the locking is reasonable given that the lua API is quite
low-level in nature. For debugging reasons it might be good to be able
to build the library with some checks in place of the current locks.
Shouldn't it also be safe to allow context switches in the counthook
handler?

Well, it's an idea anyway.

I could implement the possibly blocking file system scans using external
programs and some popen_select(cmd, handler_fn) kludge instead of threads
so easily installable thread support isn't absolute necessary. It would
be good to have decent thread support, though.

-- 
Tuomo