UNIX signals & C++

[maxmagna]

Hello,

I am looking for material that describes how *precisely* UNIX-based
signals interact with the normal C++ execution flow of control and
guidelines on how to treat signals in an "object-oriented style".

So far I have not been able to locate much on the subject. Can anyone
provide any pointer/information or suggestion?

Thanks, max
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

[Victor Bazarov]

maxmagna wrote:

I am looking for material that describes how *precisely* UNIX-based
signals interact with the normal C++ execution flow of control and
guidelines on how to treat signals in an "object-oriented style".

So far I have not been able to locate much on the subject. Can anyone
provide any pointer/information or suggestion?

I'd try a UN*X newsgroup, like comp.unix.*** or comp.os.unix.** *
Also, don't discount the newsgroup that discusses your compiler.

[Alf P. Steinbach]

* maxmagna:

I am looking for material that describes how *precisely* UNIX-based
signals interact with the normal C++ execution flow of control and
guidelines on how to treat signals in an "object-oriented style".

So far I have not been able to locate much on the subject. Can anyone
provide any pointer/information or suggestion?

§1.9/9:
"When the processing of the abstract machine is interrupted by a signal,
the values of objects with type other than volatile sig_atomic_t are
unspecified, and the value of any object not of volatile sig_atomic_t
that is modified by the handler becomes undefined."

§18.7/5:
.... "All signal handlers shall have C linkage. A POF [Plain Old Function]
that could be used as a signal handler in a conforming C program does not
produce undefined behavior when used as a signal handler in a C++ program.
The behavior of any other function used as a signal handler in a C++
program is implementation defined.(footno te 213)"

(footnote 213) "In particular, a signal handler using exception handling is
very likely to have problems"
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Dietmar Kuehl]

Victor Bazarov wrote:

maxmagna wrote:

I am looking for material that describes how *precisely* UNIX-based
signals interact with the normal C++ execution flow of control and
guidelines on how to treat signals in an "object-oriented style".

I'd try a UN*X newsgroup, like comp.unix.*** or comp.os.unix.** *
Also, don't discount the newsgroup that discusses your compiler.

Well, signals are part of the C standard library and thus also part
of standard C++. Of course, the guarantees they offer in the standard
version are rather slim: essentially, you can only assign to an object
of type 'sig_atomic_t volatile' (see 7.14.1.1 paragraph 5) or terminate
the program. I would claim that there is not much "object oriented
style" to use in this case. Actually, I claim that there is not much
"object oriented style" to be used in general because object
orientation (in the sense of using dynamic polymorphism) is just one
of many tools and it is grossly overused but this is a completely
different issue.

The only thing I can image which would warrant some encapsulation is
installing and restoring signal handlers using RAII-techniques.
--
<mailto:di***** ******@yahoo.co m> <http://www.dietmar-kuehl.de/>
<http://www.contendix.c om> - Software Development & Consulting

[maxmagna]

Thanks for the explanations and pointers to what the standard specifies.

My question is motivated by the fact that I'm trying to understand
how to write "safe" C++ code in presence of signals.

Of course, one alternative would be to totally ignore signals.
However, not all signals can be ignored. So, I would like to figure out
a clean manner to do clean up and gracefully end the application.
I have found pointers like "Delivering Signals for Fun and Profit"
by Michal Zalewski, that clearly shows how dangerous signals and
clean up operations can be. But I have not found a description of
what a solution to the problem may be.
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG