Re: SIGINT, longjmp, getaddrinfo

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

On Tue, Feb 9, 2016 at 4:29 AM, Hal Murray <hmurray@megapathdsl.net> wrote:
> I'm working on some code that wants to use ^C to bail out from working on a
> command and get back to the top of the read/dispatch loop.

OK.

> 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
> setjmp/longjmp to sigsetjmp/siglongjmp solved the problem, I think, but
> leaves me confused.

OK, probably a mistake somewhere, you failed to restore the signal mask.

> Poking around with google didn't find anything that discusses this case.  (I
> might have missed it.)  I did find various examples using longjmp from a
> signal handler, but none that I looked at suggested that I should use
> siglongjmp or really should avoid jmp-ing if at all possible.

You can use any of longjmp or siglongjmp depending on what you want to
do and exactly what you need to support.

Jumping out of an asynchronous-signal handler leaves you in
asynchronous-signal context, and so you may only call async-signal
safe functions after that point.

To reiterate: After jumping out of an AS handler you may only call
AS-safe functions.

> Now that I think about it, jmp-ing out of getaddrinfo or other arbitrary code
> seems like a bad idea.  Or at least a very complicated one.  The code doesn't
> get a chance to clean up.  In the getaddrinfo case, there is the possibility
> to leave a socket opened or leak some storage.  But maybe getaddrinfo is
> smart enough to mask SIGINT until it is ready.  (I've noticed unexpected
> delays while trying to ^C out of various utilities when they were doing DNS
> lookups.  I don't remember any details.)  But only SIGINT was masked.  There
> could also be timer interrupts.  My man pages don't mention masking any
> interrupts...

No code protects against signals like this. It would cause very large
signal handling latency e.g. your signal would be pending for a long
time while the various library routines finish.

> Is this a well know can-of-worms?  If so, can somebody point me at the
> appropriate FAQ or discussion?

It is not a can of worms.

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.

Cheers,
Carlos.