Re: Announcement of Lua Power Patch: Interpreter Bailout Flag

[Chip Salzenberg <chip@...>]

On Thu, Jul 17, 2008 at 12:53:48AM +0300, ketmar wrote:
> On Wed, 16 Jul 2008 14:42:12 -0700
> Chip Salzenberg <chip@pobox.com> wrote:
> 
> > 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!" problem.
> you can set 'count hook' after creating Lua state and then
> atomically check 'stop now' flag in this hook. it wouldn't be 'immediate
> stop' (without sacrificing performance), but it can work fine (and it
> works for me). the big plus (i think) that i can see where script was
> interrupted (with help of debug traceback). just fine-tune counter
> (once per 100 VM commands, once per 1000, etc). i think this can solve
> most of the problems.

I find that you're right, the debug hook holds a promising practical angle
to stop a Lua state without changing the core.  But it's not a generally
safe facility; it is only usable for some special cases.  Fortunately, my
case is one of them.  More detail:

If I initialize the state with a hook and a very high count; and then later
call lua_sethook() from a second thread and all the values are the same as
before *except* for the count(s); then I'll have something that's definitely
safe and apparently functional for 'stop now' purposes.

But it's not safe for the general case of altering the hook count
arbitrarily.  A little memory reordering and the effect of the change can
easily be delayed for one more cycle of the old count (and in my case, the
old count will be effectively infinite).  A hacky workaround is to call
lua_sethook() twice.

And of course it's not at all safe if you're trying to change the hook
function and the hook bits at the same time.

Anyway, I think it's a solution I can live with.  I'll report if otherwise.
Thanks in any case.
-- 
Chip Salzenberg <chip@pobox.com>