Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > pitfalls of signals

Reply
Thread Tools

pitfalls of signals

 
 
Mantorok Redgormor
Guest
Posts: n/a
 
      10-31-2003
Should I just avoid them?
I have heard many bad things about them
1) if you set a signal handler, you can't really ignore the signal and
continue with normal program execution, because after that undefined
behavior is invoked.

2) if you have a signal handler set for say SIG_INT and you continue
to reset the handler after you received the signal, to continue normal
program execution, and the signal is received twice or something you
end up invoking undefined behavior and re-entry of a signal handler
function causing major problems

what are some other things i should be aware of for signals?

and what should i do about points 1 and 2?

there really is no alternative to a portable function like signal but
signal itself seems to be a hazardous piece of crap
 
Reply With Quote
 
 
 
 
Dave Vandervies
Guest
Posts: n/a
 
      10-31-2003
In article <(E-Mail Removed) >,
Mantorok Redgormor <(E-Mail Removed)> wrote:
>Should I just avoid them?
>I have heard many bad things about them
>1) if you set a signal handler, you can't really ignore the signal and
>continue with normal program execution, because after that undefined
>behavior is invoked.


This is not universally true and, in the cases where it is true, is a
red herring.

If you have a signal handler that was invoked as a result of your program
calling raise(), then the signal is handled in a well-defined manner and
you can continue your program exactly the same way as if you had just
called the signal handler directly (unless you call raise() or abort()
in the signal handler; in that case you've invoked undefined behavior
before the normal program execution continues (N869 7.14.1.1#4)).

If a signal handler is invoked asynchronously because of an external event
unrelated to a computational exception, then normal program execution
continues after the handler returns, without invoking undefined behavior
(unless you've invoked undefined behavior in the handler by calling a
library function other than the ones you're specifically permitted to
call) (N869 7.14.1.1#3).

If a signal handler is invoked because of a computational exception, the
program has already invoked undefined behavior (f'rexample, by dividing
by zero or dereferencing a bad pointer) (N869 7.14.1.1#3); the signal
handler is your chance to clean up some things and terminate somewhat less
ungracefully (which, unless you can do it without calling any library
functions, invokes more undefined behavior), or possibly fix the cause
of the error (the way to do that will be completely system-specific),
also invoking undefined behavior.

So the only way undefined behavior can be invoked by a signal handler
ignoring the cause of the signal and returning (allowing the program to
continue) is if the signal was raised because something in the program
already invoked undefined behavior.


>2) if you have a signal handler set for say SIG_INT and you continue
>to reset the handler after you received the signal, to continue normal
>program execution, and the signal is received twice or something you
>end up invoking undefined behavior and re-entry of a signal handler
>function causing major problems


I'm not quite sure what you're trying to say here, but if you're worried
about the signal handler getting re-invoked because a signal is raised
before the handler finishes, I don't think that's a problem.
Implementations are allowed to do one of two things to deal with this:
-Temporarily block a set of signals that includes the one the handler
is dealing with until the handler finishes. In this case the signal
handler cannot be re-entered as a result of another signal being
received, so there is no problem.
-Reset the handler for that signal to SIG_DFL before invoking the handler.
In this case, the user-defined handler will not be re-entered unless
the handler reinstates itself for that signal. If the handler does
things that shouldn't be done in overlapping calls, then just don't
reinstate the signal until those things are complete. Since a signal
handler is explicitly permitted to reinstate itself (N869 7.14.1.1#5),
the implementation is responsible for making sure that nothing invokes
undefined behavior by stepping on its toes after it's done so.


>what are some other things i should be aware of for signals?


The standard specification of signal handling (section 7.14 in N869 (and
I assume C99 as well), or its equivalent in C90), plus the platform's
specification of signal handling for every platform you're supporting.


>and what should i do about points 1 and 2?


Understand them well enough to know better than to worry about them.


>there really is no alternative to a portable function like signal but
>signal itself seems to be a hazardous piece of crap


The portable parts aren't dangerous, and the dangerous parts aren't
portable, so I don't see a problem here.

signal itself really isn't as portable as it looks; all it does is provide
a portable way to hook into system-specific behavior (like computational
exceptions and external interruptions) or know that the implementation
doesn't support it.

It's perfectly valid for signal() to always return SIG_ERR, which will
make it pretty much useless for anything you wanted to do with it.


dave

--
Dave Vandervies http://www.velocityreviews.com/forums/(E-Mail Removed)
Therefore using Venn diagrams, I own the only cardboard box on the web,
which has its own set of software drivers.
--Chris Hacking in the scary devil monastery
 
Reply With Quote
 
 
 
 
Mantorok Redgormor
Guest
Posts: n/a
 
      11-02-2003
(E-Mail Removed) (Dave Vandervies) wrote in message news:<bnu4dh$ik5$(E-Mail Removed)>...
> In article <(E-Mail Removed) >,
> Mantorok Redgormor <(E-Mail Removed)> wrote:
> >Should I just avoid them?
> >I have heard many bad things about them
> >1) if you set a signal handler, you can't really ignore the signal and
> >continue with normal program execution, because after that undefined
> >behavior is invoked.

>
> This is not universally true and, in the cases where it is true, is a
> red herring.
>
> If you have a signal handler that was invoked as a result of your program
> calling raise(), then the signal is handled in a well-defined manner and
> you can continue your program exactly the same way as if you had just
> called the signal handler directly (unless you call raise() or abort()
> in the signal handler; in that case you've invoked undefined behavior
> before the normal program execution continues (N869 7.14.1.1#4)).
>
> If a signal handler is invoked asynchronously because of an external event
> unrelated to a computational exception, then normal program execution
> continues after the handler returns, without invoking undefined behavior
> (unless you've invoked undefined behavior in the handler by calling a
> library function other than the ones you're specifically permitted to
> call) (N869 7.14.1.1#3).
>
> If a signal handler is invoked because of a computational exception, the
> program has already invoked undefined behavior (f'rexample, by dividing
> by zero or dereferencing a bad pointer) (N869 7.14.1.1#3); the signal
> handler is your chance to clean up some things and terminate somewhat less
> ungracefully (which, unless you can do it without calling any library
> functions, invokes more undefined behavior), or possibly fix the cause
> of the error (the way to do that will be completely system-specific),
> also invoking undefined behavior.
>
> So the only way undefined behavior can be invoked by a signal handler
> ignoring the cause of the signal and returning (allowing the program to
> continue) is if the signal was raised because something in the program
> already invoked undefined behavior.
>
>
> >2) if you have a signal handler set for say SIG_INT and you continue
> >to reset the handler after you received the signal, to continue normal
> >program execution, and the signal is received twice or something you
> >end up invoking undefined behavior and re-entry of a signal handler
> >function causing major problems

>
> I'm not quite sure what you're trying to say here, but if you're worried
> about the signal handler getting re-invoked because a signal is raised
> before the handler finishes, I don't think that's a problem.
> Implementations are allowed to do one of two things to deal with this:
> -Temporarily block a set of signals that includes the one the handler
> is dealing with until the handler finishes. In this case the signal
> handler cannot be re-entered as a result of another signal being
> received, so there is no problem.
> -Reset the handler for that signal to SIG_DFL before invoking the handler.
> In this case, the user-defined handler will not be re-entered unless
> the handler reinstates itself for that signal. If the handler does
> things that shouldn't be done in overlapping calls, then just don't
> reinstate the signal until those things are complete. Since a signal
> handler is explicitly permitted to reinstate itself (N869 7.14.1.1#5),
> the implementation is responsible for making sure that nothing invokes
> undefined behavior by stepping on its toes after it's done so.
>


Well this explains it: http://razor.bindview.com/publish/papers/signals.html


>
> >what are some other things i should be aware of for signals?

>
> The standard specification of signal handling (section 7.14 in N869 (and
> I assume C99 as well), or its equivalent in C90), plus the platform's
> specification of signal handling for every platform you're supporting.
>
>
> >and what should i do about points 1 and 2?

>
> Understand them well enough to know better than to worry about them.
>
>
> >there really is no alternative to a portable function like signal but
> >signal itself seems to be a hazardous piece of crap

>
> The portable parts aren't dangerous, and the dangerous parts aren't
> portable, so I don't see a problem here.
>
> signal itself really isn't as portable as it looks; all it does is provide
> a portable way to hook into system-specific behavior (like computational
> exceptions and external interruptions) or know that the implementation
> doesn't support it.
>
> It's perfectly valid for signal() to always return SIG_ERR, which will
> make it pretty much useless for anything you wanted to do with it.
>
>
> dave


- nethlek
 
Reply With Quote
 
Dave Vandervies
Guest
Posts: n/a
 
      11-02-2003
In article <(E-Mail Removed) >,
Mantorok Redgormor <(E-Mail Removed)> wrote:
>(E-Mail Removed) (Dave Vandervies) wrote in message
>news:<bnu4dh$ik5$(E-Mail Removed)>...
>> In article <(E-Mail Removed) >,
>> Mantorok Redgormor <(E-Mail Removed)> wrote:
>> >Should I just avoid them?
>> >I have heard many bad things about them
>> >1) if you set a signal handler, you can't really ignore the signal and
>> >continue with normal program execution, because after that undefined
>> >behavior is invoked.

>>
>> This is not universally true and, in the cases where it is true, is a
>> red herring.


<snip detailed explanation>

>> >2) if you have a signal handler set for say SIG_INT and you continue
>> >to reset the handler after you received the signal, to continue normal
>> >program execution, and the signal is received twice or something you
>> >end up invoking undefined behavior and re-entry of a signal handler
>> >function causing major problems

>>
>> I'm not quite sure what you're trying to say here, but if you're worried
>> about the signal handler getting re-invoked because a signal is raised
>> before the handler finishes, I don't think that's a problem.


<snip another detailed explanation>

>Well this explains it: http://razor.bindview.com/publish/papers/signals.html


This looks pretty unix-specific to me, so comp.unix.programmer would
probably be a better place to discuss specific problems related to it
than comp.lang.c .

It seems to me, though, that all of the problems noted there are caused
by asynchronous signal handlers doing things that are specifically stated
to cause undefined behavior if done in an asynchronous signal handler,
so saying that signals are unsafe because of this is a lot like saying
that dynamic memory allocation is unsafe because using a pointer that's
been freed invokes undefined behavior. The correct solution is to be
aware of the restrictions that need to be observed and to be careful
(or to use constructs that are harder to do dangerous things with if
you're unwilling or unable to do so).


dave

--
Dave Vandervies (E-Mail Removed)
If his homework involves writing DOS programs, he probably needs all the
help he can get.
--Richard Heathfield in comp.lang.c
 
Reply With Quote
 
Villy Kruse
Guest
Posts: n/a
 
      11-04-2003
On Fri, 31 Oct 2003 16:59:29 +0000 (UTC),
Dave Vandervies <(E-Mail Removed)> wrote:


>
>I'm not quite sure what you're trying to say here, but if you're worried
>about the signal handler getting re-invoked because a signal is raised
>before the handler finishes, I don't think that's a problem.
>Implementations are allowed to do one of two things to deal with this:
>-Temporarily block a set of signals that includes the one the handler
> is dealing with until the handler finishes. In this case the signal
> handler cannot be re-entered as a result of another signal being
> received, so there is no problem.
>-Reset the handler for that signal to SIG_DFL before invoking the handler.
> In this case, the user-defined handler will not be re-entered unless
> the handler reinstates itself for that signal. If the handler does
> things that shouldn't be done in overlapping calls, then just don't
> reinstate the signal until those things are complete. Since a signal
> handler is explicitly permitted to reinstate itself (N869 7.14.1.1#5),
> the implementation is responsible for making sure that nothing invokes
> undefined behavior by stepping on its toes after it's done so.
>



The end result will be quite different. When a new signal arrives while
the handler is set to SIG_DFL the result can be quite catastrofic for
the process, considering the normal action of SIG_DFL is to terminate
the process.


Villy
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
A must-read article: Keep Sites Running Smoothly By Avoiding These 10 Common ASP.NET Pitfalls Juan T. Llibre ASP .Net 9 07-11-2006 07:15 PM
ASP.NET Profile Provider benefits and pitfalls? =?Utf-8?B?dmE=?= ASP .Net 0 03-24-2006 12:36 AM
pitfalls Developing now with VS2005 and SQL Server 2005 Carlos ASP .Net 1 11-07-2005 09:31 PM
File Locking Conflicts - Are there any pitfalls ? Geoffrey Python 2 07-07-2004 04:16 PM
Pitfalls of using a Global Response.Redirect spamfurnace ASP .Net 1 05-24-2004 12:36 AM



Advertisments