Re: awakeFromNib vs appdidfinishlaunching
Re: awakeFromNib vs appdidfinishlaunching
- Subject: Re: awakeFromNib vs appdidfinishlaunching
- From: Derrick Bass <email@hidden>
- Date: Wed, 22 Mar 2006 17:22:00 -0600
- Resent-date: Wed, 22 Mar 2006 17:22:35 -0600
- Resent-from: Derrick Bass <email@hidden>
- Resent-message-id: <email@hidden>
- Resent-to: Cocoa <email@hidden>
On Mar 22, 2006, at 11:01 AM, Ondra Cada wrote:
Karim,
On 22.3.2006, at 17:38, Karim Morsy wrote:
yea, I'm doing all of the lengthy tasks on threads ... but as far
as canceling is concerned, is there any simple way (other than
using darwin notifications or distributed objects) for stopping a
secondary thread from the main thread?
Sure: you ask it to stop and wait till it does.
Since threads are by far not as encapsulated as tasks, it is plain
impossible to force stop a thread (other than by crashing it along
with all the others :))
That's not entirely true. pthreads, upon which Cocoa threads are
layered, does have a pthread_cancel function. That function will call
cleanup handlers that have been registered for the thread. So, with
some work, you could make sure that any thread-private resources
you've created are released if the thread is terminated. However,
since Apple's code isn't open, there's no way to be sure what thread-
private resources Cocoa/QuickTime/CoreAudio/etc have allocated
without you knowing about it. (Although it may be that those
frameworks "do the right thing" and register their own cleanup
handlers with the pthreads system.)
In summary, it's possible, but there's a strong possibility of
leaking memory and maybe some chance of messing up Cocoa/QuickTime/
etc entirely. (And, of course, you'll never be able to reproduce a
bug like that.) I've never been brave enough to try this approach.
Derrick
_______________________________________________
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