[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Lua and signals
- From: William Ahern <william@...>
- Date: Wed, 26 Dec 2012 15:41:11 -0800
On Wed, Dec 26, 2012 at 07:19:39PM +0000, Owen Shepherd 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?
Whether sigprocmask works in a threaded environment is unspecified according
to POSIX. It works on some systems, but not on others. I forget which ones,
but it's definitely a mixed bag.
A bigger problem is that threads might not work--depending on the system--at
all unless the startup environment links with pthreads, so luaposix can't
itself merely link pthreads at runtime and use pthread_sigmask. For example,
the Lua interpreter must be built with pthreads support. Again, I forget
which systems have this requirement. Some of the BSDs, IIRC, which don't
want to bother with the considerable additional library and linker
complexity.
> Note that some glibc functions start internal threads...
Are you sure? AFAIU, only if linked against pthreads, but I'm willing to be
proven wrong.
> 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.
Perl has been doing this for ages. There are problems, of course, but
fortunately Perl's experience has documented all the caveats.
> Note that stdio and malloc are not signal safe. Handling signals
> asynchronously from a non- native language is just not going to work
But they're not being handled asynchronously; they're being handled
synchronously. The obvious problem is delayed--up to and including
never--handler execution.
> Iirc there are at least two specialized signal libraries. Have you tried
> them?
FWIW, my cqueues library has a synchronous signals module supporting
Solaris, OpenBSD, NetBSD, FreeBSD, OS X, and Linux. More noteworthy, I
document the various mechanisms--pselect, kqueue, signalfd--in the
documentation, particularly regarding their interaction with signal masks
and handlers.