Re: Lua and signals

[Sean Conner <sean@...>]

It was thus said that the Great Luiz Henrique de Figueiredo once stated:
> > 2. It calls lua_sethook from inside the signal handler. Where anybody gets
> > the idea this is a clever thing to do, never mind the inkling that it might
> > work when the documentation says nothing to that effect, I have no idea.
> 
> The standalone interpreter does this and it seems to work fine; lua_sethook
> just sets a flag. Of course, it is true that standalone interpreter has
> different requirements than a user application. In particular, the only
> signal handling in the standalone interpreter is to handle interruptions.
> 
> My lalarm library uses the same technique for raising alarms and again it
> seems to work just fine.
> 
> Note that in both cases the signal handler just sets a flag. The signal
> itself is "handled" in Lua only when it is safe to do so, that is, outside
> the actual C signal handler.

  It's how my own signal interface works [1].  The handler sets a flag [2]
which can be checked later.  In fact, that's about the only thing a signal
handler *can* do portably and safely.  Yes, POSIX lists several functions as
"async-signal-safe" but the list is mostly of Unix system calls; write() is
fine, but not printf() (or similar type calls) and *definitely not*
malloc()/free() [3] but overall, the less you do in a signal handler, the
better.

  -spc (not a fan of Unix signals)

[1]	It's buried in a larger source file dealing with Unix processes:
	https://github.com/spc476/lua-conmanorg/blob/master/src/process.c

[2]	of type "volatile sig_atomic_t".  The POSIX stardard states that
	a type of "sig_atomic_t" can store values between 0 and 255; outside
	that range is undefined.  Such variables should be "volatile" to
	prevent the compiler from optimizing out checks.

[3]	I once spent a month tracking down a random crash that was the
	result of calling malloc() (indirectly, through several layers of
	code) in the signal handler.