Re: Exiting non-POSIX threads?
Re: Exiting non-POSIX threads?
- Subject: Re: Exiting non-POSIX threads?
- From: "j.carlson" <email@hidden>
- Date: Tue, 30 Jul 2013 05:32:03 -0400
On July 30, 2013 at 12:04:44 AM, email@hidden (email@hidden) wrote:
Message: 5
Date: Mon, 29 Jul 2013 12:54:26 +0300
From: Oleg Krupnov <email@hidden>
To: Steve Sisak <email@hidden>
Cc: Cocoa-Dev List <email@hidden>
Subject: Re: Exiting non-POSIX threads?
Message-ID:
<email@hidden>
Content-Type: text/plain; charset=ISO-8859-1
Thanks for your answer, Steve, but the problem remains.
In my case, the exception has already been thrown inside the block and
I cannot catch it or modify it in any way in my handler. I'm basically
writing an uncaught exception handler. My app should show a crash
report window and then terminate itself.
Shortest path in this case may be to wrap dispatch_async() and pass a block which executes the block parameter (currently passed to dispatch_async()) but this added block introduces your exception handling. Be sure to copy the block parameter, as dispatch_async() would.
Remember that exceptions originating from Cocoa APIs are generally nonrecoverable (C++ implementations OTOH are generally designed to be safe to catch and resume -- recoverable without leaking resources or leaving them in potentially invalid states).
Assume killing threads is never an option ;) Just let them exit naturally so that all implementations within that context may conclude what they are in the process of executing. Sometimes that means you must choose (or design) more robust implementations.
So when you catch that halting exception, then you can add some work to the main run loop (e.g. to present the alert). You should then suspend the thread which handled the exception (until your process is exited from the other thread after the alert you mentioned was presented) to avoid returning control flow to the implementation/queue which executed your block. Make sure your presentation is quick and always exits, and avoid creating autoreleased objects in the suspended thread (the pools will not be drained).
Of course, if it's your API that throws nonrecoverable exceptions you should just use another mechanism for error handling to avoid all the above (and perhaps recover gracefully).
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden