site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com User-agent: Microsoft-Entourage/10.1.6.040913.0 circa 2/8/05 1:31 PM, "Rick Steele" <wildsync@wildsync.com> wrote:
In any case, the list of things one may do in a signal handler is so restricted that I would not attempt to generalize it up to the C++ level anyway. As soon as any destructor does anything as simple as call delete, Bad ThingsĀ are likely to break loose from the ceiling and rain down around your ears.
Does this mean that a hard drive and remote network systems could blow up, or that the computer freeze could occur?
Depends on what kind of code you're writing, but in general if you are talking about signal handlers then you are talking about userland code, and so the worst likely consequence would be that your own program would misbehave in some way catastrophic to its own operation (dereference a wild pointer [and thus crash], enter an endless loop [and thus freeze], etc.). But anything is possible; your program might well become confused and write garbage into its own data files before blowing up. Depends on the program.
As a general rule, callback functions available to C programmers should never allow C++ exceptions to escape.
I don't really understand this last sentence. How would a C callback let an C++ exception handler "escape".
Various APIs, such as the signal handling APIs, are expressed in terms of C. C++ will allow you to call C APIs, which includes passing the addresses of callback functions declared as part of those APIs, but even though a callback may be invoked as if it were a C function, if it is written in C++ then it is a C++ function. The caller doesn't know this, and isn't prepared to handle C++ exceptions which may be thrown by the callback. Consequently, a C callback written in C++ must catch all exceptions. (I often toss them into a queue for later analysis and reporting.) -- Pete Gontier http://www.m-audio.com/ _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com
participants (1)
-
Pete Gontier