Re: Clarification: What is exatly drawing inside a thread
Re: Clarification: What is exatly drawing inside a thread
- Subject: Re: Clarification: What is exatly drawing inside a thread
- From: Stefan Pantke <email@hidden>
- Date: Mon, 9 Feb 2004 13:04:17 +0100
OK, once I added [imageOutletOL lockFocusIfCanDraw], the application
runs
now in stress test mode around 6 times longer - but that's not long
enough...
The crucial point seems to be image loading - still.
Once I disable Image loading, the app seems to crash no longer. Image
loading is
performed like this:
>>>
// downloadedData asserted to be != nil at this point
currentImage = [[NSImage alloc]
initWith
Data:downloadedData];
if ( nil != currentImage ) {
// Insert the downloaded GIF, PDF, etc. image
into the window
[globalDataLock lock];
{
if( [imageOutletOL lockFocusIfCanDraw] ) {
[imageOutletOL setImage:currentImage];
[imageOutletOL unlockFocus];
// print it's name
[previewNameOL
setStringValue:[myDownloadLocation lastPathComponent]];
}
// [currentImage autorelease];
[currentImage release];
}
[globalDataLock unlock];
<<<
I'm going crazy, although I think it s note safe, it still hangs.....
Any hint very welcome!
Kind regards,
Stefan
Am 08.02.2004 um 09:00 schrieb Glen Low:
Probably because setStringValue: isn't an atomic operation and is not
thread safe. So without a lock you will have several threads that are
executing that method at the same time which might lead to all sorts
of problems.
Or more general: How to determine, which operations DRAW and which
do not?
I don't think this has anything to do with drawing at all.
Did you check what values the shared object actually holds? Try to
log them and see what you get. I guess it will be the same garbage
you see drawn to the screen.
In general, you always have to use locks when writing to shared
resources from more than one thread.
I think it's even more severe than that. You may religiously use your
own locks when using setStringValue: but there's no guarantee that the
system i.e. Cocoa or AppKit will do so when accessing its data e.g.
invalid rects or strings -- after all, any such lock is unknown by
system code. For example, suppose setStringValue: updates the invalid
rect at the same time as the system is using it to figure out what to
draw -- by locking that code, you can be sure only one thread updates
the invalid rect, but you haven't prevented the system from using it
to figure out what to draw. lockFocusIfCanDraw does seem to use a lock
known by Cocoa or AppKit.
It looks like a general method of getting what you want is using
NSConnection to get a proxy of the NSTextView, then do a
setStringValue on it. Others may want to comment whether an NSView is
too heavyweight to be accessed through a proxy.
Cheers, Glen Low
---
pixelglow software | simply brilliant stuff
www.pixelglow.com
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.