Re: Lua and signals

[Andres Perera <andres.p@...>]

On Wed, Dec 26, 2012 at 2:49 PM, Owen Shepherd <owen.shepherd@e43.eu> wrote:
> I just looked at the code of luaposix. It doesn't, as I initially feared,
> just call back into Lua from the signal handler. It does however do two
> terrible things which make it's reliability suspect
>
> 1. It calls sigprocmask, a function which just flat out doesn't work if the
> process has threads and who knows if anybody has started any? Note that some
> glibc functions start internal threads...

The glibc functions that start pthreads need to document that. In the
context of POSIX, no library other than libc can spawn pthreads in the
calling process as an internal detail, unless they subsume the work of
libc by providing required symbols during the linking process. In the
case of libc, functions that are documented by POSIX (even implicitly)
as working in tandem with sigprocmask would need inner bookkeeping
(locking) if they were to use pthreads as an implementation detail. If
glibc breaks that contract, which I highly doubt, then glibc is at
fault, no one else is.

> 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.

As somebody else pointed out, lua code doesn't get executed in
interrupt context.