Re: NSImage from bitmap - then delete bitmap
Re: NSImage from bitmap - then delete bitmap
- Subject: Re: NSImage from bitmap - then delete bitmap
- From: Graham Cox <email@hidden>
- Date: Sat, 23 Jul 2016 12:29:07 +1000
> On 23 Jul 2016, at 12:45 AM, Trygve Inda <email@hidden> wrote:
>
> Because the main thread sometimes needs to ask the worker threads to
> terminate. If it does this after performOnMainThread has been called by a
> worker thread, but before the main thread has processed it, then the main
> thread will block waiting for the worker thread to exit, but the worker
> thread has already blocked when it called performOnMainThread.
>
> Very rare, but it can happen.
This is wrong thinking.
If the worker thread is waiting for -performOnMainThread to complete, it *cannot* possibly get a call from the main thread to terminate, because the main thread is dealing with whatever the other thread asked it to do.
If the worker thread performs a copy and doesn’t wait for the main thread to perform the drawing, then it’s still “blocked” while it’s performing the copy.
Either your understanding of the bug is wrong, or there’s somethomg whiffy in your architecture.
Usually a worker thread just checks a flag on each loop and falls out when it gets set (by another thread). That flag should be set atomically. There can then be no deadlock.
e.g.
worker thread:
while( self.running )
{
// do work
window.imageRep = myResult; // window.imageRep is (atomic, copy)
[performOnMainThread: window.setNeedsDisplay]; // this is obviously pseudocode!
}
main thread, when it needs to terminate worker thread:
workerThread.running = NO;
both workerThread.running and window.imageRep are atomic properties.
—Graham
_______________________________________________
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