Re: More Mac like handling of OS raised exceptions
Re: More Mac like handling of OS raised exceptions
- Subject: Re: More Mac like handling of OS raised exceptions
- From: Greg Hurrell <email@hidden>
- Date: Tue, 16 May 2006 14:41:44 +0200
El 16/05/2006, a las 13:32, Ondra Cada escribió:
The reasonable way is
(i) to catch any catchable exception (signal, whatever);
(ii) in the handler, to save changes(*) far as technically
possible, of course *not* overwriting the previous save, for the
bug may have caused data inconsistence. Still it's much better to
have, say, a document with one paragraph mangled, than no document
at all;
(iii) only after that, to "crash" (i.e., terminate reporting a
problem), preferrably incl. sending the crash report home
automatically (with the user confirmation of course, but without
having him to send an e-mail explicitly: a number of them won't care).
All good points. I guess I was speaking from my own experience with
non-document-based applications (where there's nothing you'd save
anyway).
Of course, Lon will need to bear in mind that the list of functions
that are safe to call from within a signal handler is pretty limited
(see the "sigaction" man page), and even something innocuous like
objc_msgSend is off-limits. See the thread "how do I save prefs when
the app is Force Quit?" from a couple of days ago, in which Apple's
Greg Parker wrote:
The list of "things you're allowed to do in a signal handler" is
short. Sending Objective-C messages is not one of them. Neither is
calling exit() or doing anything with CFPreferences.
The problem is locks. A signal interrupts a thread, and the
interrupted thread may be holding locks. If the signal handler
tries to use the same locks, it deadlocks. For example, malloc()
uses locks. The program will hang if the signal interrupts a malloc
() call and then calls malloc() itself.
objc_msgSend() may take locks and may call malloc(), so it can't be
used from a signal handler. CFPreferences may call malloc() and
uses its own locks internally, so you can't call it either. exit()
invokes atexit handlers, which may do arbitrary unsafe things.
You can find a list of signal-safe functions in the sigaction(2)
man page. In particular, you should use _exit() and write() instead
of exit() and printf().
Cheers,
Greg
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden