Re: SIGINT, longjmp, getaddrinfo

[Hal Murray <hmurray at megapathdsl dot net>]

Thanks for all the replies.


carlos@systemhalted.org said:
> To reiterate: After jumping out of an AS handler you may only call AS-safe
> functions. 

There is no hint of that in my man page for longjmp/siglongjmp.  (Most Linux 
distros have the same page from 2009-01-13.)

It does say:
       longjmp() and siglongjmp() make programs hard to understand  and  main-
       tain.  If possible, an alternative should be used.

but I didn't interpret "hard to understand" as hinting at the sorts of 
problems I encountered.

The NetBSD man page does have an interesting CAVEAT:
     Use of longjmp() or siglongjmp() from inside a signal handler is not as
     easy as it might seem.  Generally speaking, all possible code paths
     between the setjmp() and longjmp() must be signal race safe.
     Furthermore, the code paths must not do resource management (such as
     open(2) or close(2)) without blocking the signal in question, or
     resources might be mismanaged.  Obviously this makes longjmp() much less
     useful than previously thought.


[maybe some routines mask or intercept signals or ...]
carlos@systemhalted.org said:
> 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. 

readline installs its own signal handlers.  The man page doesn't mention it, 
but a break at sigprocmask shows it getting called from rl_set_signals and 
google finds
  2.5 Readline Signal Handling
  http://www.delorie.com/gnu/docs/readline/rlman_43.html

carlos@systemhalted.org said:
> Alternatively use threads and pthread_cancel. 

That's the cleanest suggestion I've seen so far.


godmar@gmail.com said:
>> 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. 

The man pages for many routines have a section on thread safety.  I don't 
remember ever seeing one on AS safety.


godmar@gmail.com said:
> Personally, though, I agree that the global flag approach will likely be
> better. 

What does something like getnameinfo do when it gets an EINTR  while waiting 
for a packet to arrive?

How does it know that a SIGINT handler set a flag and wants to bail as 
compared to a timer went off and it should continue.

---------------

I poked around some more.  I think longjmp-ing out of getnameinfo is leaving 
SIGINT masked.  Is that surprising?  or reasonable?  A break at sigprocmask 
found the readline stuff mentioned above but nothing from getnameinfo.  If 
it's interesting, I'll try to put together a simple test program.


I'm still surprised that there isn't some web page that documents and 
discusses this whole area.

-- 
These are my opinions.  I hate spam.