lua-users home
lua-l archive

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


On Mon, Apr 12, 2010 at 6:25 PM, Patrick Donnelly <batrick@batbytes.com> wrote:
> As I've told Matthew but will also state here. The crux of the problem
> is we cannot set the hook on the running Lua thread. Before we would
> save the thread that called signal() and set the hook on it when a
> signal is received. This leaves us with the problem of that thread
> either (a) being garbage collected or (b) not running again for some
> indeterminate amount of time. Despite this being a signal handling
> library, I felt this type of unpredictable behavior was unsuitable
> (heh).

You can find the global state from the lua_State struct, by bypassing
the public API. Makes
your code only work with 5.1, but in 5.2 there is a function to find
the global state. You could
wrap it in a function and ifdef it based on lua version, even.

Also, you can put a userdata in the registry, and hook __gc to find
out when the global state
is destroyed.

Btw, I looked at this lib a while ago, hopeing to find an
implementation of sigaction (I want
system calls not to restart on SIGINT, since restarting after SIGINT
is handled effectively makes it so SIGINT
is ignored by the lua hook mechanism when it occurs during long
running system calls).

I noticed your code doesn't reset the signal handler after it's
caught, though, in it's handling of SIGINT. This is incompatible
with lua.c, and it would make things worse for us, right now ctrl-c
twice will kill lua when it's blocked in a restartable
system call, with your code, ctrl-c would never get noticed.

Anyhow, your library isn't about sigaction, that's OK.

But, did I miss it? Is it possible to set the sig handler to SIG_IGN
or SIG_DFL? I just saw a way to set it
back to it's "original" behaviour.

And why do you go through the effort of counting signals? Signal
delivery is not reliable, the pending
signals are a bitmask, there is no counting for non-realtime signals.

Cheers,
Sam