[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Announcement of Lua Power Patch: Interpreter Bailout Flag
- From: Chip Salzenberg <chip@...>
- Date: Wed, 16 Jul 2008 14:42:12 -0700
On Thu, Jul 17, 2008 at 12:09:50AM +0300, ketmar wrote:
> On Wed, 16 Jul 2008 14:04:51 -0700
> Chip Salzenberg <email@example.com> wrote:
> > So, this is a supported behavior/usage? Specifically, setting the
> > debug hook on a running state from another thread?
> this is what LHF did in his 'alarm' library, if i understand you
> correctly. you can set debug hook from C callback, for example, and then
> do everything you need in the context of the running interpreter.
I've found the lalarm module. Its approach happens to work with signal
handlers in single-threaded programs because during signal handling the main
thread is stopped. But there's a pretty awful race condition in any other
case. Here's the key bit of lua_sethook, which is called from the signal
handler in LHF's code:
L->hook = func;
L->basehookcount = count;
L->hookmask = cast_byte(mask);
Executing that code against a *running* state from another thread is simply
not safe. And because it is not portable to depend on store order of
memory, let alone what the compiler is allowed to rearrange, just altering
the order of the statements would not cure this problem.
If a way could be found to atomically install new debug hook settings from
another thread, then sure, that'd be a fine solution to the "STOP NOW!"
Chip Salzenberg <firstname.lastname@example.org>