Re: lua_signal

[Patrick Donnelly <batrick@...>]

On Tue, Apr 13, 2010 at 4:03 PM, Sam Roberts <vieuxtech@gmail.com> wrote:
> On Tue, Apr 13, 2010 at 11:28 AM, Matthew Wild <mwild1@gmail.com> wrote:
>> The solution I added was to queue the signals (as you can see in the Prosody version of lua-signal), Patrick uses simply a counter. Both methods work, and I don't see how POSIX could possibly say we can't do either of these things :)
>
> You are are allowed, and are doing it.
>
> Anybody sending signals in rapid sucession will find that sometimes
> the OS drops them (POSIX), but that sometimes they are delivered to
> the process, and in that case luasignal will queue them.

Quite true.

> Having an API that purports to do something that can't reliably be
> done gave me the impression that the author did not understand the
> POSIX signal model, sorry, I'll move on.

But now you are insinuating here, publicly, that I do not understand
the standard. Further, this implies my library is of poor quality. You
are forcing me to respond.

I make no guarantees on multiple signal delivery in the library. What
I do *try* to promise is that if the OS delivers the signal to me, I
will try to deliver the signal to you. I can't always keep that
promise because (a) there is too long a pause between hook calls or
(b) some unavoidable race conditions prevent me from tracking the
signal occurrence. What my library *does* promise is that if a signal
occurs between hook calls, then your handler *will* run on the next
hook call. Anything more than that (extra signal deliveries in the
queue) is extra *but allowed by the standard in any case*.

For your information, signal queuing is talked about in Steven's [1]
on page 283. (While I'm not really blocking the signal delivery, the
lua application views the library as doing so until the hook runs. I
safely feel the extra layer of abstraction does not violate the
standard.)

[1] Advanced Programming in the UNIX Environment. Stevens, Richard.
1993. First Edition.

-- 
- Patrick Donnelly