Re: detachDrawingThread:toTarget:withObject: vs detachNewThreadSelector:toTarget:withObject:
Re: detachDrawingThread:toTarget:withObject: vs detachNewThreadSelector:toTarget:withObject:
- Subject: Re: detachDrawingThread:toTarget:withObject: vs detachNewThreadSelector:toTarget:withObject:
- From: j o a r <email@hidden>
- Date: Thu, 28 Sep 2006 18:54:42 +0200
On 28 sep 2006, at 10.47, Antonio Nunes wrote:
Ah, I get your point. Well, the objective is indeed to make sure
that for the object in question only a single thread has access to
that block of code at a time. The code block itself is small (five
lines) and pretty self contained. (It accesses a PDFPage it has
cached to obtain and store both a data representation of it and a
PDFDocument representing the page.) Since potentially both the main
thread and a secondary thread may need to access the code block for
that object at the same time, it needs the lock.
Note that it's not always enough to ensure single thread concurrent
access to an object. It's quite common that classes require access
from _only_ the main thread. This is not particularly well documented
for the classes that make up Cocoa, but it is a fact non the less. I
would be especially careful about accessing AppKit objects from non-
main threads. Unless explicitly stated as supported, I would view it
as not supported.
j o a r
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