 |
lua-l archive |
|
|
||
|
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...
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.
Note that stdio and malloc are not signal safe. Handling signals asynchronously from a non- native language is just not going to work
Iirc there are at least two specialized signal libraries. Have you tried them?
On 26 Dec 2012 15:59, "Bernd Eggink" <monoped@sudrala.de> wrote:
Hi,
I wonder if signal handling (as in luaposix) is supposed to work in any situation. Or are there limitations, preconditions etc.(on Linux)?
I'm asking because I have a program where signal() simply doesn't work. After putting
local P = require "posix"
P.signal(P.SIGUSR1, function() print("signal") end)
at the beginning of the program, I expect the command "kill -s USR1 $pid" to print "signal", but instead the program exits immediately. This even happens when the signal handling function is completely empty.
The program in question is pretty complex. However, in simple test programs signal() works as expected.
Any ideas what could prevent signal() from working correctly?
Greetings,
Bernd