Re: lua_signal

[Patrick Donnelly <batrick@...>]

Hi Sam,

On Mon, Apr 12, 2010 at 10:05 PM, Sam Roberts <vieuxtech@gmail.com> wrote:
> 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.

Yes well, that's about as undesirable as the current situation : /

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

I don't see how that helps.

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

I tried to not have the library make any assumptions about behavior
(e.g., changing to default after signal receipt until hook runs). The
library right now replaces the SIGINT handler of the interpreter
because it needs a hook for all Lua threads. If you desire the
application to close then use Ctrl+\ for SIGQUIT?

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

signal("SIGINT", nil) --> default SIGINT
signal("SIGINT", function() end) --> ignore SIGINT

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

POSIX.1 allows for a signal to be delivered more than once when a
process unblocks a signal. Intuitively, we go into a blocked state
whenever we are running Lua code but periodically check via a hook for
signals.

-- 
- Patrick Donnelly