Re: SIGINT, longjmp, getaddrinfo

["Carlos O'Donell" <carlos at systemhalted dot org>]

On Tue, Feb 9, 2016 at 10:05 AM, Godmar Back <godmar@gmail.com> wrote:
> On Tue, Feb 9, 2016 at 5:16 AM, Carlos O'Donell <carlos@systemhalted.org> wrote:
>>
>> On Tue, Feb 9, 2016 at 4:29 AM, Hal Murray <hmurray@megapathdsl.net> wrote:
>>
>> > The symptom is that ^C stopped working.  A few printf-s later, I discovered
>> > that the SIGINT handler was being called with SIGINT masked.  Switching from
>
> (Responding to original email:)
>
> That's not really a surprise. SIGINT is always masked when the SIGINT
> handler is called, read the documentation:
> http://www.gnu.org/software/libc/manual/html_node/Blocking-for-Handler.html
>
> "When a handler function is invoked on a signal, that signal is
> automatically blocked"

Right.

>> To reiterate: After jumping out of an AS handler you may only call
>> AS-safe functions.
>
> That's not always true in my opinion. It's true only if the main code
> was able to enter any C library function that is not AS-safe.

Correct. My statement was not 100% precise. If main calls only AS-safe
functions then the interrupting AS may jump out of the AS context and
call any functions it wants, either AS-safe or AS-unsafe, but then you
have the same problem again. If you handle another signal and have
called any AS-unsafe functions, then you are again restricted to
AS-safe functions only. You would have to mask SIGINT during calls to
AS-unsafe functions (as you suggest below).

>> I expect that you really can't live with the above restriction of
>> calling only AS-safe functions after the jump out of the signal
>> handlers. Therefore you need to rework your code such that the AS
>> handler sets a global that is inspected by the main loop.
>> Alternatively use threads and pthread_cancel.
>
> Another alternative is to rework the main code to block/mask the
> SIGINT signal during any portion in which AS-unsafe functions may be
> invoked. If his application involves large blocks of libc-unrelated
> computation, that may be feasible without undue latency (he'd still be
> able to longjmp out of the handler).
>
> Personally, though, I agree that the global flag approach will likely be better.

Agreed.

Cheers,
Carlos.