X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C88EE6.9A18F650@onstor-exch02.onstor.net>; Tue, 25 Mar 2008 19:10:45 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Subject: RE: Debian Linux signal that was use..
Date: Tue, 25 Mar 2008 19:10:45 -0700
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E07A8DAFD@onstor-exch02.onstor.net>
In-Reply-To: <20080325190522.4897b065@ripper.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Debian Linux signal that was use..
Thread-Index: AciO5dmfnxdA1bU2Ru+NcKp4AybM/QAAK0qA
From: "Mike Lee" <mike.lee@onstor.com>
To: "Andy Sharp" <andy.sharp@onstor.com>
Cc: "Tim Gardner" <tim.gardner@onstor.com>,
	"Kumar Vakacharla (HCL)" <kumarv@onstor.com>


Andy:

Your lunch is on me tomorrow.
Thanks!

-Mike
-----Original Message-----
From: Andy Sharp=20
Sent: Tuesday, March 25, 2008 6:05 PM
To: Mike Lee
Cc: Larry Scheer; Tim Gardner; Svati Chandra
Subject: Re: Debian Linux signal that was use..


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
>=20
> >  -----Original Message-----
> > From: 	Larry Scheer =20
> > 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..
> >=20
> > 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:
> >=20
> > Svati, this is not complete confirmation but it is another
> > indication that what we use would follow  the "BSD behavior."
> >=20
> > 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.
> >=20
> >        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.
> >=20
> >        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.
> >=20
> >        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.
> >=20
> > NOTES
> >        The effects of this call in a multi-threaded process are
> > unspecified.
> >=20
> >        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> =
]
> >=20
