Re: hook question

[Rici Lake <lua@...>]

On 11-Oct-06, at 9:41 PM, Glenn Maynard wrote:

> As for the VM releasing the lock: that's the purpose of 
> luai_threadyield,
> right?

Ah, good point. I hadn't noticed that.

However:

  function forever() return forever() end

:)

As for sethook, if there were any doubt, wouldn't it be easier to 
simply make the hook fields in lua_State atomic_t? Or is that not 
guaranteed to exist?

> I'm interested in anyone else's experiences with threading Lua.  Note
> that my need for it has nothing to do with performance, but that I
> want to be able to load data--which calls Lua--in one thread, while
> allowing rendering to be driven by Lua in another thread.  A global
> Lua lock causes needless contention between the two, with eg. a lengthy
> load causing rendering to freeze.

My attempts to use threaded Lua weren't all that successful, although I 
haven't tried with 5.1. In particular, I found the fact that all Lua 
threads would freeze during a garbage collection to be problematic; 
this would be less serious with 5.1, but still an issue. And, as you 
say, the overhead of constantly locking and unlocking. Since it's not 
particularly costly to maintain multiple unrelated Lua states, I've 
gone that route, although it makes data sharing a bit awkward.

> Can you use luai_userstateopen to set a default hook, to propagate
> any active hook into the new state (or if not, could that be made
> to work)?

I don't see why that wouldn't work.