Subject: RE: signal handler context...
To: 'gabriel rosenkoetter' <gr@eclipsed.net>
From: Stephane St Hilaire <ssthilaire@hyperchip.com>
List: tech-kern
Date: 01/31/2002 13:20:03
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C1AA83.E708B5F0
Content-Type: text/plain;
charset="iso-8859-1"
On Thu, Jan 24, 2002 at 12:02:26PM -0800, Bill Studenmund wrote:
>> I disagree with the part after, "might as well." Knowing the routine
needs
>> to know if it was called in a signal handler does not mean that you
>> shouldn't call it from a signal handler, just that you need to tell it if
>> you are in a signal handler.
>>
>> If you're writing a signal handler, you should know that there are fewer
>> things you can do in it, so telling library functions that they are in a
>> signal handler shouldn't be a surprise. :-)
>In the general case, I agree. In this specific case, I understood
>the point to be that the application programmer might not be clued
>enough to do things right, and Stephane was trying to save him from
>shooting himself in the foot.
The problem being that when someone shoots himself in the foot he usually
tries to blame it on somebody else. If you are in charge of maintaining
libraries and that they are misused by "bad/inexperienced/add politically
correct term here" programmers then you're gonna spend a lot of time with
them first finding out that they called you from a signal handler and
telling them that they should never have done this and that you actually had
documented that in header files and other documentation. If there was a
simple boolean type OS provided call to know whether or not I'm getting
called from a signal handler, I could at least in the debug version of the
library throw some assertion/log a text message telling the programmer that
he shouldn't bother me with this problem. In release mode I might want to
help him out in terms of not leaving is process hanging indefinitively...
I've done some tricks to trap this such as registering signal handlers from
within the library during init type calls and keeping the address of the
previously registered handlers but these are not 100% reliable mechanisms.
>(This is not to say that I think there's a way to do that, just that
I'm sure there is a way. I expect that whatever piece of code calls the
signal handler knows what it is doing when it's doing it.
>I'm not sure this is much of a compromise, and it'd maybe be better
>to come at the problem from a different angle.)
A different angle would mean one where an attempt to solve it is actually
performed. Maybe years from now something will be defined... I'm obviously
not holding my breathe.
Steph
------_=_NextPart_001_01C1AA83.E708B5F0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: signal handler context...</TITLE>
</HEAD>
<BODY>
<BR>
<P><FONT SIZE=3D2>On Thu, Jan 24, 2002 at 12:02:26PM -0800, Bill =
Studenmund wrote:</FONT>
<BR><FONT SIZE=3D2>>> I disagree with the part after, "might =
as well." Knowing the routine needs</FONT>
<BR><FONT SIZE=3D2>>> to know if it was called in a signal =
handler does not mean that you</FONT>
<BR><FONT SIZE=3D2>>> shouldn't call it from a signal handler, =
just that you need to tell it if</FONT>
<BR><FONT SIZE=3D2>>> you are in a signal handler.</FONT>
<BR><FONT SIZE=3D2>>> </FONT>
<BR><FONT SIZE=3D2>>> If you're writing a signal handler, you =
should know that there are fewer</FONT>
<BR><FONT SIZE=3D2>>> things you can do in it, so telling library =
functions that they are in a</FONT>
<BR><FONT SIZE=3D2>>> signal handler shouldn't be a surprise. =
:-)</FONT>
</P>
<P><FONT SIZE=3D2>>In the general case, I agree. In this specific =
case, I understood</FONT>
<BR><FONT SIZE=3D2>>the point to be that the application programmer =
might not be clued</FONT>
<BR><FONT SIZE=3D2>>enough to do things right, and Stephane was =
trying to save him from</FONT>
<BR><FONT SIZE=3D2>>shooting himself in the foot.</FONT>
</P>
<P><FONT SIZE=3D2>The problem being that when someone shoots himself in =
the foot he usually tries to blame it on somebody else. If you are in =
charge of maintaining libraries and that they are misused by =
"bad/inexperienced/add politically correct term here" =
programmers then you're gonna spend a lot of time with them first =
finding out that they called you from a signal handler and telling them =
that they should never have done this and that you actually had =
documented that in header files and other documentation. If there was a =
simple boolean type OS provided call to know whether or not I'm getting =
called from a signal handler, I could at least in the debug version of =
the library throw some assertion/log a text message telling the =
programmer that he shouldn't bother me with this problem. In release =
mode I might want to help him out in terms of not leaving is process =
hanging indefinitively...</FONT></P>
<P><FONT SIZE=3D2>I've done some tricks to trap this such as =
registering signal handlers from within the library during init type =
calls and keeping the address of the previously registered handlers but =
these are not 100% reliable mechanisms.</FONT></P>
<BR>
<P><FONT SIZE=3D2>>(This is not to say that I think there's a way to =
do that, just that</FONT>
<BR><FONT SIZE=3D2>I'm sure there is a way. I expect that whatever =
piece of code calls the signal handler knows what it is doing when it's =
doing it.</FONT></P>
<P><FONT SIZE=3D2>>I'm not sure this is much of a compromise, and =
it'd maybe be better</FONT>
<BR><FONT SIZE=3D2>>to come at the problem from a different =
angle.)</FONT>
<BR><FONT SIZE=3D2>A different angle would mean one where an attempt to =
solve it is actually performed. Maybe years from now something will be =
defined... I'm obviously not holding my breathe.</FONT></P>
<BR>
<P><FONT SIZE=3D2>Steph</FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C1AA83.E708B5F0--