AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20080325190452.3fdc0bde@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<mike.lee@onstor.com>,<larry.scheer@onstor.com>,<tim.gardner@onstor.com>,<schandra@onstor.com>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/andys@onstor.net@onstor-exch02.onstor.net/INBOX	0	BB375AF679D4A34E9CA8DFA650E2B04E07A8DAFA@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Tue, 25 Mar 2008 19:05:22 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Mike Lee" <mike.lee@onstor.com>
Cc: "Larry Scheer" <larry.scheer@onstor.com>, "Tim Gardner"
 <tim.gardner@onstor.com>, "Svati Chandra" <schandra@onstor.com>
Subject: Re: Debian Linux signal that was use..
Message-ID: <20080325190522.4897b065@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E07A8DAFA@onstor-exch02.onstor.net>
References: <BB375AF679D4A34E9CA8DFA650E2B04E056C94EF@onstor-exch02.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E07A8DAFA@onstor-exch02.onstor.net>
Organization: Onstor
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Yes there is, I'll do the code review.

I take it this is the review information:


Changelist #  28506



On Tue, 25 Mar 2008 18:59:16 -0700 "Mike Lee" <mike.lee@onstor.com>
wrote:

> Larry:
> Thanks for the research.
> I guess there is no weaseling my way out of this code review
> now...  :) -Mike
> 
> >  -----Original Message-----
> > From: 	Larry Scheer  
> > Sent:	Tuesday, March 25, 2008 5:55 PM
> > To:	Tim Gardner
> > Cc:	Mike Lee; Svati Chandra; Andy Sharp
> > Subject:	Debian Linux signal that was use..
> > 
> > Tim, Mike,
> >     There is no bsd/signal.h in our debian packages because, if you
> > believe the man pages, it follows the BSD behavior. We are using the
> > glibc2 library.
> > Here is what the man page says about the signal we are using:
> > 
> > Svati, this is not complete confirmation but it is another
> > indication that what we use would follow  the "BSD behavior."
> > 
> > PORTABILITY
> >        The original Unix signal() would reset the handler to
> > SIG_DFL, and Sys-
> >        tem  V  (and the Linux kernel and libc4,5) does the same.  On
> > the other
> >        hand, BSD does not reset the handler, but blocks new
> > instances of  this
> >        signal from occurring during a call of the handler.  The
> > glibc2 library
> >        follows the BSD behaviour.
> > 
> >        If one on a libc5 system includes <bsd/signal.h> instead of
> > <signal.h>
> >        then  signal()  is  redefined  as  __bsd_signal  and signal
> > has the BSD
> >        semantics.  This is not recommended.
> > 
> >        If one on a  glibc2  system  defines  a  feature  test  macro
> > such  as
> >        _XOPEN_SOURCE  or  uses  a  separate  sysv_signal function,
> > one obtains
> >        classical behaviour.  This is not recommended.
> > 
> >        Trying to change the semantics of this call using defines and
> > includes
> >        is not a good idea.  It is better to avoid signal()
> > altogether, and use
> >        sigaction(2) instead.
> > 
> > NOTES
> >        The effects of this call in a multi-threaded process are
> > unspecified.
> > 
> >        The routine handler must be very careful,  since  processing
> > elsewhere
> >        was interrupted at some arbitrary point. POSIX has the
> > concept of "safe
> >        function".  If a signal interrupts  an  unsafe  function,
> > and handler
> >        calls  an  unsafe  function, then the behavior is undefined.
> > Safe func-
> >        tions are listed explicitly in the various standards.  The
> > POSIX.1-2003
> >        list is [qute extensive read the rest of the man page here:
> > <http://ripper/cgi-bin/man/man2html/usr/share/man/man2/signal.2.gz> ]
> > 
