Hello,
is there a possibility to prevent a process from termination when a user
presses CTRL-C? Or is it possible to catch this user abortion request and
program my own abortion-handler which is invoked by pressing CTRL-C, before
the process actually aborts?
Nnamdi
Nnamdi Kohn <nnamdi.kohn@web.de> wrote:
NK > Hello,
NK > is there a possibility to prevent a process from termination when a user
NK > presses CTRL-C? Or is it possible to catch this user abortion request and
NK > program my own abortion-handler which is invoked by pressing CTRL-C, before
NK > the process actually aborts?
NK > Nnamdi
Yes. Look at the signal() function in the docs.
Trap for the Ctrl-C is (I think) SIGINT. If I’m wrong, look in
/usr/include/signal.h for the names of the other signals.
You would set up your own handler function to handle the signal. It
could decide to terminate the program if it wants to, or not. It may
want to do some clean up before terminating. Etc.
Good luck.
Yes you can. First, define your handler and a sigaction structure :
void handler(int signal)
{
switch(signal)
{
case SIGINT : printf(“SIGINT received\n”); do_what_you_want(); break;
default : printf(“Other signal received\n”);
}
}
struct sigaction action;
And then specify action to be associated with SIGINT :
action.sa_handler = handler;
sigaction(SIGINT, &action, NULL);
Hope that helps !
Hello,
is there a possibility to prevent a process from termination when a user
presses CTRL-C? Or is it possible to catch this user abortion request and
program my own abortion-handler which is invoked by pressing CTRL-C,
before
the process actually aborts?Nnamdi
Thanks. This works.
“Raphaël HUCK” <raphael.huck@free.fr> schrieb im Newsbeitrag
news:c1vkc9$ehc$1@inn.qnx.com…
Yes you can. First, define your handler and a sigaction structure :
void handler(int signal)
{
switch(signal)
{
case SIGINT : printf(“SIGINT received\n”); do_what_you_want(); break;
default : printf(“Other signal received\n”);
}
}struct sigaction action;
And then specify action to be associated with SIGINT :action.sa_handler = handler;
sigaction(SIGINT, &action, NULL);
Hope that helps !Hello,
is there a possibility to prevent a process from termination when a user
presses CTRL-C? Or is it possible to catch this user abortion request
and
program my own abortion-handler which is invoked by pressing CTRL-C,
before
the process actually aborts?Nnamdi
\
You have to be careful about what you’re doing in a signal handler.
Most library functions are considered signal-unsafe, which means that
you shouldn’t call them from a signal handler unless you can guarantee
that the signal did not interrupt a signal-unsafe function. In
particular, if the Ctrl-C interrupts a printf() call, calling printf()
again in the signal handler has a reasonable chance of corrupting some
data structures, possibly causing a crash.
Raphaël HUCK wrote:
Yes you can. First, define your handler and a sigaction structure :
void handler(int signal)
{
switch(signal)
{
case SIGINT : printf(“SIGINT received\n”); do_what_you_want(); break;
default : printf(“Other signal received\n”);
}
}struct sigaction action;
And then specify action to be associated with SIGINT :action.sa_handler = handler;
sigaction(SIGINT, &action, NULL);
Hope that helps !
Hello,is there a possibility to prevent a process from termination when a user
presses CTRL-C? Or is it possible to catch this user abortion request and
program my own abortion-handler which is invoked by pressing CTRL-C,before
the process actually aborts?
Nnamdi
\
“Wojtek Lerch” <Wojtek_L@yahoo.ca> wrote in message
news:c1vqfd$buq$1@inn.qnx.com…
You have to be careful about what you’re doing in a signal handler.
Most library functions are considered signal-unsafe, which means that
you shouldn’t call them from a signal handler unless you can guarantee
that the signal did not interrupt a signal-unsafe function. In
particular, if the Ctrl-C interrupts a printf() call, calling printf()
again in the signal handler has a reasonable chance of corrupting some
data structures, possibly causing a crash.
Not to mention that you don’t know what state internal library
syncronization objects are at the time when the signal hit you. Nothing
like a dose of potential deadlock to go with your side of corruption.
The great thing about signals is they can be async. The bad thing about
signals is they can be async.
–
Cheers,
Adam
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>
“Adam Mallory” <amallory@qnx.com> wrote in message
news:c1vv1p$n64$1@inn.qnx.com…
“Wojtek Lerch” <> Wojtek_L@yahoo.ca> > wrote in message
news:c1vqfd$buq$> 1@inn.qnx.com> …
You have to be careful about what you’re doing in a signal handler.
Most library functions are considered signal-unsafe, which means that
you shouldn’t call them from a signal handler unless you can guarantee
that the signal did not interrupt a signal-unsafe function. In
particular, if the Ctrl-C interrupts a printf() call, calling printf()
again in the signal handler has a reasonable chance of corrupting some
data structures, possibly causing a crash.Not to mention that you don’t know what state internal library
syncronization objects are at the time when the signal hit you. Nothing
like a dose of potential deadlock to go with your side of corruption.The great thing about signals is they can be async. The bad thing about
signals is they can be async.
To address these problems, use signal masking so as to allow signal
interrupts to happen only during safe portions of your program.
–
Cheers,
AdamQNX Software Systems Ltd.
[ > amallory@qnx.com > ]With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net
“Dean Douthat” <deanz1@comcast.net> wrote in message
news:c2fgi0$isj$1@inn.qnx.com…
To address these problems, use signal masking so as to allow signal
interrupts to happen only during safe portions of your program.
That’s obvious - the hard part is knowing where and when it’s required. In
addition, masking signals doesn’t help all the time as some signals are not
maskable.
–
Cheers,
Adam
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>