lua-users home
lua-l archive

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


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.