Preemptive multithreading in Lua

2
votes

I'm using lua as the scripting language for handling events in my application, and I don't want to restrict users to writing short handlers - e.g. someone might want to have one handler run an infinite loop, and another handler would interrupt the first one. Obviously, lua doesn't directly support such behavior, so I'm looking for workarounds.

First of all, I'd like to avoid modifying the engine. Is it possible to set up a debug hook that would yield once the state has reached its quota? Judging by the documentation, it shouldn't be hard at all, but I don't know if there are any caveats to this.

And second, can I use lua_close to terminate a thread as I would in actual multithreading?

1
multithreadinglua
What platform is this running on? I would suggest using the threading mechanisms already built into your environment. – Brad Peabody
I'm pretty sure attempting to operate on the same lua_State from two different threads would cause bad things to happen. – riv
Oh I see what you mean. I was thinking of having multiple lua_States but having them "wrap" one set of underlying objects (C structs or C++ objects with LuaBind or whatever). Depending on what your requirements are and how you want to deal with the locking issues, that might work. But it's tricky (i.e. you get to deal with all of the synchronization issues yourself). – Brad Peabody
Yeah I want them to work in the same scope, so they can share globals etc. I'm hoping that if I only hook lines, then the lines themselves could be considered atomic operations, which should solve most sync issues that arise in regular multithreading (using common sense, of course) – riv
Right. Seems like that would work. Sounds like fun - good luck to you :) – Brad Peabody

1 Answers

1
votes

I've done something similar in the past. Its completely possible to multi-thread on separate Lua states. Be sure to take a look at luaL_lock() and luaL_unlock() (plus associated setup/cleanup), as you will no doubt need this setup (a simple mutex should do the trick).

After that, it should be a fairly simple matter of creating a lock/wait/interrupt API for your handlers.