Re: C API to check VM is running?

[Sean Conner <sean@...>]

It was thus said that the Great Xin Zhao once stated:
> thank you for your reply.
> I read your blog and code carefully. It made me learn a lot.
> 
> Yes, using signal functions is very dangerous, but read the source
> code, lua_sethook is safe to be called in signals. so I used it.

  I'm wondering why you are using signals for this.  I know on Linux, you
can link a program with the "-pg" options to generate an executable that can
be run to generate profile information.  On the Mac and Solaris (and I
believe FreeBSD), you don't even need to do that as you can use dtrace to
profile any arbitrary program.  And I'm sure there are ways of profiling
under Windows (although I am not familiar with Windows).

  In my experience, signal handlers are not worth the effort.

> /*
> ** This function can be called asynchronously (e.g. during a signal).
> ** Fields 'oldpc', 'basehookcount', and 'hookcount' (set by
> ** 'resethookcount') are for debug only, and it is no problem if they
> ** get arbitrary values (causes at most one wrong hook call). 'hookmask'
> ** is an atomic value. We assume that pointers are atomic too (e.g., gcc
> ** ensures that for all platforms where it runs). Moreover, 'hook' is
> ** always checked before being called (see 'luaD_hook').
> */
> LUA_API void lua_sethook (lua_State *L, lua_Hook func, int mask, int count) {
> 
> My goal is to only analyze lua code hotspots.
> And the reason why I did not use lua debug sampling is because 90% of
> the code in our program is lua, and lua also calls many bound C++
> functions.
> The problem with lua debug is slow and inaccurate, because the
> execution time of each instruction is different. 

  A hot spot will show up regardless of frequency of sample.  Yes, profiling
code may slow it down, but the profiling overhead isn't counted when
profiling.  As I mentioned in my post

	http://boston.conman.org/2019/08/21.1

I used a rather large timing interval at first, and the hot spot jumped out. 
When I ran it with an interval that was 1/10th the size (10 times more
frequently) the hot stop didn't change.

> It may take more time
> to run 1 instructions than 100 instruction, such as calling a bound
> C++ function to write a file.

  I only wrote the output at the end of the run, not as it was running.

> Currently this profiling tool is running well, of course, as you see,
> the code below is bad, and may be only work at my machine.
> 
> unsigned short nny = *(unsigned short *)((char*)L+196);
> unsigned short nCcalls = *(unsigned short *)((char*)L+198);
> 
> so may be it would be better if there is a C API here. to check lua VM
> is running.

  Include lstate.h so you don't have to manually calculate the offsets.

  -spc