Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Why do signals exist?

Reply
Thread Tools

Why do signals exist?

 
 
vippstar@gmail.com
Guest
Posts: n/a
 
      01-28-2008
What is the purpose of signals and why do they exist in C?
thanks in advance
 
Reply With Quote
 
 
 
 
Walter Roberson
Guest
Posts: n/a
 
      01-28-2008
In article <(E-Mail Removed)>,
<(E-Mail Removed)> wrote:
>What is the purpose of signals and why do they exist in C?


That sounds eirily like a class assignment question...

--
So you found your solution
What will be your last contribution?
-- Supertramp (Fool's Overture)
 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      01-28-2008
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> What is the purpose of signals and why do they exist in C?
> thanks in advance


Signals are C's model of mechanisms most operating environments
provide to handle two kinds of events: erroneous or exceptional
conditions arising from a program's own actions (for example, when
it divides by zero or dereferences NULL), and interventions from
outside the program (for example, hitting ^C to interrupt it). A
C program can set up "signal handlers," special functions that are
called when these exceptional or external events occur; the handler
can respond to the event in some appropriate way.

The details of exactly how these events arise, are dispatched,
and are processed vary greatly from one O/S to another, so the
C Standard says very little about what really goes on: It doesn't
list all the possible signals, it doesn't say which can be ignored
and which cannot, it doesn't say what happens if a signal handler
tries to resume normal operation after most signals. In a sense,
the Standard's mechanism for signals is mostly a "stub," a plain-
vanilla interface to a realm whose details are mostly outside the
Standard itself. Thus, there is not a lot you can do with signals
in portable C code, because even though the signal() function is
a portable interface, the thing it interfaces with is non-portable.
A program that makes non-trivial use of signals is usually tied
pretty tightly to the specifics of a particular O/S.

--
Eric Sosman
(E-Mail Removed)lid
 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      01-28-2008
(E-Mail Removed) wrote:

> What is the purpose of signals and why do they exist in C?
> thanks in advance


They exist to provide asynchronous notification of events to the
program. The C99 Standard defines six standard signals. Implementations
may define more and almost everything about handling signals is
implementation defined. POSIX provides richer signal support and more
guarantees on behaviour.

See section 7.14 of the Standard.

 
Reply With Quote
 
vippstar@gmail.com
Guest
Posts: n/a
 
      01-28-2008
On Jan 28, 8:25 pm, (E-Mail Removed)-cnrc.gc.ca (Walter Roberson)
wrote:
> In article <(E-Mail Removed)>,
>
> <(E-Mail Removed)> wrote:
> >What is the purpose of signals and why do they exist in C?

>
> That sounds eirily like a class assignment question...

Perhaps you'll feel better if you hear that I am a hobby programmer.
 
Reply With Quote
 
vippstar@gmail.com
Guest
Posts: n/a
 
      01-28-2008
On Jan 28, 8:34 pm, Eric Sosman <(E-Mail Removed)> wrote:
> (E-Mail Removed) wrote:
> > What is the purpose of signals and why do they exist in C?
> > thanks in advance

>
> Signals are C's model of mechanisms most operating environments
> provide to handle two kinds of events: erroneous or exceptional
> conditions arising from a program's own actions (for example, when
> it divides by zero or dereferences NULL), and interventions from
> outside the program (for example, hitting ^C to interrupt it). A
> C program can set up "signal handlers," special functions that are
> called when these exceptional or external events occur; the handler
> can respond to the event in some appropriate way.
>
> The details of exactly how these events arise, are dispatched,
> and are processed vary greatly from one O/S to another, so the
> C Standard says very little about what really goes on: It doesn't
> list all the possible signals, it doesn't say which can be ignored
> and which cannot, it doesn't say what happens if a signal handler
> tries to resume normal operation after most signals. In a sense,
> the Standard's mechanism for signals is mostly a "stub," a plain-
> vanilla interface to a realm whose details are mostly outside the
> Standard itself. Thus, there is not a lot you can do with signals
> in portable C code, because even though the signal() function is
> a portable interface, the thing it interfaces with is non-portable.
> A program that makes non-trivial use of signals is usually tied
> pretty tightly to the specifics of a particular O/S.



Thanks mr Sossman, but I still don't see the reason why ISO C would
need signals.
I understand why a standard like POSIX would need them, but I don't
understand ISOs decision to include them in standard C.
I also think you misunderstood my question, perhaps it was poorly
worded.
I do know what signals are for (as a concept in programming) but I did
not understand the concept behind signals in ISO C, and their use.
Then again, perhaps it was me who misunderstood.
 
Reply With Quote
 
vippstar@gmail.com
Guest
Posts: n/a
 
      01-28-2008
On Jan 28, 8:37 pm, santosh <(E-Mail Removed)> wrote:
> (E-Mail Removed) wrote:
> > What is the purpose of signals and why do they exist in C?
> > thanks in advance

>
> They exist to provide asynchronous notification of events to the
> program. The C99 Standard defines six standard signals. Implementations
> may define more and almost everything about handling signals is
> implementation defined. POSIX provides richer signal support and more
> guarantees on behaviour.
>
> See section 7.14 of the Standard.


What greatly annoys me is that I must have signals in mind when
programming in ISO C.
I believe they should not be part of the language and I see no reason
for them to be.
I am also aware of POSIX signals, and it makes sense for such standard
to have signals but not for ISO C.
 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      01-28-2008
(E-Mail Removed) wrote:

> On Jan 28, 8:37 pm, santosh <(E-Mail Removed)> wrote:
>> (E-Mail Removed) wrote:
>> > What is the purpose of signals and why do they exist in C?
>> > thanks in advance

>>
>> They exist to provide asynchronous notification of events to the
>> program. The C99 Standard defines six standard signals.
>> Implementations may define more and almost everything about handling
>> signals is implementation defined. POSIX provides richer signal
>> support and more guarantees on behaviour.
>>
>> See section 7.14 of the Standard.

>
> What greatly annoys me is that I must have signals in mind when
> programming in ISO C.


You don't have to. You can completely ignore the existence of signals if
you want to. In fact, that's what most small C programs will do. The OS
and your C runtime library will take the default action for any signals
delivered, which usually means termination.

> I believe they should not be part of the language and I see no reason
> for them to be.


You may have a point.

> I am also aware of POSIX signals, and it makes sense for such standard
> to have signals but not for ISO C.


As such there is not much that ISO C /does/ define about signals, and
fortunately, it's not something you need to consider if you don't want
to. If you do need to consider signals, you'll very likely find
yourself actual coding to a more elaborate standard like POSIX.

 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      01-28-2008
(E-Mail Removed) wrote:
> On Jan 28, 8:34 pm, Eric Sosman <(E-Mail Removed)> wrote:
>> (E-Mail Removed) wrote:
>>> What is the purpose of signals and why do they exist in C?
>>> thanks in advance

>> Signals are C's model of mechanisms most operating environments
>> provide to handle two kinds of events: erroneous or exceptional
>> conditions arising from a program's own actions (for example, when
>> it divides by zero or dereferences NULL), and interventions from
>> outside the program (for example, hitting ^C to interrupt it). A
>> C program can set up "signal handlers," special functions that are
>> called when these exceptional or external events occur; the handler
>> can respond to the event in some appropriate way.
>>
>> The details of exactly how these events arise, are dispatched,
>> and are processed vary greatly from one O/S to another, so the
>> C Standard says very little about what really goes on: It doesn't
>> list all the possible signals, it doesn't say which can be ignored
>> and which cannot, it doesn't say what happens if a signal handler
>> tries to resume normal operation after most signals. In a sense,
>> the Standard's mechanism for signals is mostly a "stub," a plain-
>> vanilla interface to a realm whose details are mostly outside the
>> Standard itself. Thus, there is not a lot you can do with signals
>> in portable C code, because even though the signal() function is
>> a portable interface, the thing it interfaces with is non-portable.
>> A program that makes non-trivial use of signals is usually tied
>> pretty tightly to the specifics of a particular O/S.

>
>
> Thanks mr Sossman, but I still don't see the reason why ISO C would
> need signals.
> I understand why a standard like POSIX would need them, but I don't
> understand ISOs decision to include them in standard C.
> I also think you misunderstood my question, perhaps it was poorly
> worded.
> I do know what signals are for (as a concept in programming) but I did
> not understand the concept behind signals in ISO C, and their use.
> Then again, perhaps it was me who misunderstood.


Since most uses of signals rely on things the C Standard
does not describe, it's reasonable to wonder why the loose
descriptions are there at all. But even though the nature
and the processing of signals are highly system-specific, the
Standard still has reason to say a few things about them. For
example, the Standard describes how signals must behave w.r.t.
sequence points, thus allowing the programmer to rely on the
values of certain variables and warning him to steer clear of
others. The Standard requires that after a signal handler
returns (if it can), the interrupted function proceeds as if
nothing had happened; a signal will not, for example, restart
a loop that was already in progress. This guarantee applies
even if the signal handler calls the interrupted function; thus,
a compiler cannot say "This function calls no others and hence
cannot be called recursively; I'll take shortcuts."

So the Standard needs to talk about signals a little bit,
to constrain their behavior w.r.t. the "base" language and give
the programmer a few tools for dealing with them. Since a bare-
bones notion of signals is already present in the Standard, it
is used in a few convenient places, too: arithmetic overflow may
provoke a signal, abort() is defined in terms of SIGABRT, and
so on. Most of the serious work with signals is outside the
Standard's realm, but the Standard has a need to make a few
minimal specifications anyhow.

If the Standard is a "contract" between the C implementor
and the C programmer, the part about signals is a "treaty"
between the C implementation and the foreign realm called the O/S.

--
Eric Sosman
(E-Mail Removed)lid
 
Reply With Quote
 
Walter Roberson
Guest
Posts: n/a
 
      01-28-2008
In article <(E-Mail Removed)>,
Eric Sosman <(E-Mail Removed)> wrote:
>The Standard requires that after a signal handler
>returns (if it can), the interrupted function proceeds as if
>nothing had happened; a signal will not, for example, restart
>a loop that was already in progress. This guarantee applies
>even if the signal handler calls the interrupted function; thus,
>a compiler cannot say "This function calls no others and hence
>cannot be called recursively; I'll take shortcuts."


However, if the signal handler refers to any object with static
storage duration, and the operation is not -writing- to an
object of sig_atomic_type, the interrupted function might not
proceed "as if nothing had happened".

The C89 wording specifically prohibits calling any function in the
standard library and then talks about references to objects with static
storage duration. It seems to me that logically the implication would
be that if the signal handler calls some function that refers to an
object with static storage duration (other than writing
sig_atomic_type) that the behaviour is undefined just as if the
signal handler itself had referred to the prohibitted object;
however the transitivity of the constraint is not explicitly specified
in the C89 wording, so other people might have different interpretations.
--
"Okay, buzzwords only. Two syllables, tops." -- Laurie Anderson
 
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
Why does Modelsim not display some signals? fl VHDL 2 02-27-2013 09:32 AM
Why multiplex signals? Neha VHDL 3 03-24-2007 07:15 AM
why why why why why Mr. SweatyFinger ASP .Net 4 12-21-2006 01:15 PM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
Some signals became ? and missing on the simvision, why? Acceed See VHDL 1 04-22-2005 03:07 PM



Advertisments