Re: Announcement of Lua Power Patch: Interpreter Bailout Flag

[Chip Salzenberg <chip@...>]

On Wed, Jul 16, 2008 at 03:50:25PM -0700, Chip Salzenberg wrote:
> 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.

I knew there was something wrong with this, and now I remember what: The
--count operation in the lvm loop is *not* necessariliy an atomic operation.
So a core change actually is required *if* the core wants to guarantee that
changing count actually works.  Consider this sequence:

   RUNAWAY LVM                               MONITOR THREAD
   -----------                               --------------

   Load count (e.g. 4000) into register

   Decrement count in register               Store new tiny count (e.g. 1)

   Store decremented count (3999)

If this occurs, then the monitor thread's sethook call will have had no
effect the first time around.  And there's no guarantee that it ever will.

Therefore, if the core is not to change, the initial count value (during
normal operation) will have to be something relatively small, say 1000 or
10000.  That will impose a performance impact; a small one, I hope.

The kludge factor is really going up, I gotta say.  I wonder whether
lua_forcereturn() isn't that bad a feature after all, when compared with all
this dancing on pinheads.

PS: The monitor thread could call sethook a larger number of times (say,
    five), with system calls to relinquish the CPU in between; that
    construct increases the chance that one of the sethook calls will work.
    That's even more kludgy, of course.
-- 
Chip Salzenberg <chip@pobox.com>