signal trapping in C++

[nitroamos]

Hey guys --

I have an idea on how to make my program a bit better -- but I'm not
sure if I can do it.

Do any of you know if there is a way to have a non-static function trap
a signal from the OS? The most interesting data from my program is only
output at the very end of the program, but sometimes I realize that I
need to stop it sooner (e.g. i set a parameter such that it is running
longer than I anticipated OR it crashes OR PBS wants to kill it) and it
would be nice if before quitting I could get it to print the best
results that it has so far (from all processors when run in parallel if
possible).

It seems that you have to use a static void function for both atexit
and signal (from signal.h) callbacks, but this would require making
everything that function uses static (e.g. the classes containing all
the data), right?

is there another way?

thanks!

[Ian Collins]

ni*******@gmail.com wrote:

Hey guys --

I have an idea on how to make my program a bit better -- but I'm not
sure if I can do it.

Do any of you know if there is a way to have a non-static function trap
a signal from the OS? The most interesting data from my program is only
output at the very end of the program, but sometimes I realize that I
need to stop it sooner (e.g. i set a parameter such that it is running
longer than I anticipated OR it crashes OR PBS wants to kill it) and it
would be nice if before quitting I could get it to print the best
results that it has so far (from all processors when run in parallel if
possible).

It seems that you have to use a static void function for both atexit
and signal (from signal.h) callbacks, but this would require making
everything that function uses static (e.g. the classes containing all
the data), right?

is there another way?

No. While signals are OT here, the general concept of passing C++
method to C libraries isn't.

When passing callbacks to C, the function must have extern "C" linkage.
Some compilers will let you get away with passing a static member, but
this isn't strictly correct.

I recommend the using a plain old extern "C" function, which can, if
required, be made a friend of the class.

--
Ian Collins.

[Imre Palik]

Hi,

ni*******@gmail.com writes:

It seems that you have to use a static void function for both atexit
and signal (from signal.h) callbacks, but this would require making
everything that function uses static (e.g. the classes containing all
the data), right?

Strictly speaking, you have to use a global function here. But with quite
a few compiler you can get away with static member functions, as they tend
to have the same calling convention.

Also, it is quite limited what you may done in a signal handler. E.g.,
calling most library function is off limit. The usual practice is to
create a global variable with type sig_atomic_t, set it from the signal
handler, and query it now-and-then from your main loop.

ImRe

[Imre Palik]

Ian Collins <ia******@hotmail.com> writes:

No. While signals are OT here, the general concept of passing C++
method to C libraries isn't.

??? I thought this newsgroup is about standard C++.
And what other parts of the C++ standard are off topic here?

ImRe

[nitroamos]

thanks guys!

[Ian Collins]

Imre Palik wrote:

Ian Collins <ia******@hotmail.com> writes:

No. While signals are OT here, the general concept of passing C++
method to C libraries isn't.

??? I thought this newsgroup is about standard C++.
And what other parts of the C++ standard are off topic here?

Standard C++ knows nothing about signals.

--
Ian Collins.

[Alan Johnson]

Ian Collins wrote:

Imre Palik wrote:

Ian Collins <ia******@hotmail.com> writes:

No. While signals are OT here, the general concept of passing C++
method to C libraries isn't.

??? I thought this newsgroup is about standard C++.
And what other parts of the C++ standard are off topic here?

Standard C++ knows nothing about signals.

See 18.7.1, Table 22. C++ knows about:

Macros: SIGABRT SIGILL SIGSEGV SIG_DFL SIG_IGN SIGFPE SIGINT SIGTERM SIG_ERR
Type: sig_atomic_t
Functions: raise signal
Alan

[Jacek Dziedzic]

ni*******@gmail.com wrote:

Hey guys --

I have an idea on how to make my program a bit better -- but I'm not
sure if I can do it.

Do any of you know if there is a way to have a non-static function trap
a signal from the OS? The most interesting data from my program is only
output at the very end of the program, but sometimes I realize that I
need to stop it sooner (e.g. i set a parameter such that it is running
longer than I anticipated OR it crashes OR PBS wants to kill it) and it
would be nice if before quitting I could get it to print the best
results that it has so far (from all processors when run in parallel if
possible).

Why not log the "best result so far" periodically? If your
job is killed by the scheduler or crashes or etc. you are
left with the last version of the file containing the most
recent results.

For that nasty case that your job is killed during the
actual writing of this log, you might want to produce a
backup each time and write to a copy.

HTH,
- J.

[Ian Collins]

Alan Johnson wrote:

Standard C++ knows nothing about signals.

See 18.7.1, Table 22. C++ knows about:

Macros: SIGABRT SIGILL SIGSEGV SIG_DFL SIG_IGN SIGFPE SIGINT SIGTERM
SIG_ERR
Type: sig_atomic_t
Functions: raise signal

Thanks for the reference, my lesson for the day.

--
Ian Collins.

[Pete Becker]

Ian Collins wrote:

Standard C++ knows nothing about signals.

It knows about signal and raise, and a handful of default signals. Along
with Standard C, it doesn't know about asynchronous signals (i.e.
signals raised other than by calling raise).

--

Pete Becker
Roundhouse Consulting, Ltd.