lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On 10 January 2018 at 04:31, Dan Tull <dtull@adobe.com> wrote:
> The change to support our sampling profiler was to add a counter to the
> global part of the Lua state which could be atomically incremented from
> another thread (as long as the state was still alive). When that counter is
> non-zero, it invokes a hook function which records a traceback and the
> value of the counter (and clears the counter). This means the main overhead
> is just a slightly more complex condition at the top of luaV_execute to see
> if the hook function needs to be invoked (so zero if debugging is off
> entirely*
> and low even when debugging is enabled).
>
> This essentially charges perf time against the first Lua opcode that runs
> after a trigger is sent. We often trigger at relatively low frequencies
> (10-40 Hz
> depending on what you're trying to detect) and while it isn't perfect it's
> been
> enormously helpful to have a profiler that doesn't distort execution
> performance.
>
> It also means we can get near instant execution pausing without needing the
> count or line hook active (both of which slow down execution severely). Our
> pause function triggers the state and it halts on the next opcode.
>
> Hopefully that helps.
>
> DT

What you've described is what debug.sethook does!
L->hookmask is an atomic value, which makes it safe to set from another thread.
(see https://www.lua.org/source/5.3/ldebug.c.html#lua_sethook)

i.e. you activate the count or line hooks when you want to break; you
don't leave them active.