[asterisk-dev] signal

[Tilghman Lesher]

On Monday 18 January 2010 09:58:22 Mark Michelson wrote:
> John Todd wrote:
> > On Jan 18, 2010, at 1:29 AM, Bhrugu Mehta wrote:
> >> Hi, all
> >> in jenitor project of asterisk there is lien change signal to
> >> sigaction function, but for the competibility issue
> >> signal functin is bettor then sigaction. so it is safe to keep
> >> signal() in asterisk.
> >>
> >> regards
> >> --
> >> Bhrugu Mehta
> >> Sr. S/W Engineer (D&D)
> >> Telephony Team (Asterisk,zaptel etc.)
> >
> > Hello -
> >    I'm not quite clear on your message, and I think others may not
> > quite know what you mean as well.  Is this a question?  Can you please
> > re-state your posting, and someone will hopefully answer.
> >
> > JT
>
> I believe that he's saying that the use of signal(2) is more portable than
> the use of sigaction(2). sigaction(2) is a newer function than signal(2),
> and iirc, it is preferred because it allows you to atomically perform
> multiple actions with regards to signals as opposed to inherently having
> race conditions in your code (see the Signals chapter of Advanced
> Programming in the Unix Environment for a good discussion on the matter).
> However, I would be interested in knowing exactly why the OP thinks that
> signal(2) is a more portable choice than sigaction(2).
>
> Mark Michelson

There are two specific reasons for using sigaction(2) instead of signal(2).
The first is behavior; with signal(2), on some platforms, the signal handler
is returned to the default behavior immediately upon the firing of that
handler.  This is not desireable behavior for Asterisk.  Sigaction(2) does not
alter the signal handler when it fires.  The second advantage of sigaction(2)
is that it delivers more information than signal(2), including the address, if
any, of memory that caused the signal to be fired and the reason that the
signal was fired.

Given that sigaction(2) is better defined and is a POSIX-mandatory function,
and given our aim that Asterisk requires a POSIX system, I don't see a good
argument why we should not use sigaction(2) in preference to signal(2).

-- 
Tilghman