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: Antonio Nunes <email@hidden>
- Date: Fri, 29 Sep 2006 15:29:56 +0100
On 28 Sep 2006, at 17:54, j o a r 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.
And so we learn. Some further searching of the archives teaches that
"only a single thread may access the contents of a CGPDFDocument at
any given time", but that "it's okay for multiple threads to access
the document as long as you put in locks to enforce this constraint."
I'll assume that PDFKit encapsulates CGPDF functionality and thus is
equally sensitive to this issue.
I can only imagine concurrent access happening in my program when the
main thread tries to draw an unconverted PDFPage causing it to be
converted, while a secondary thread is converting the rest of the
PDFDocument's pages. Once a PDFPage is converted it lives in its very
own, personal, PDFDocument.
I've found no description of what happens when the same PDFDocument
is accessed by multiple threads concurrently, but I'll assume the
results are undefined and that calls may even return successfully,
with crashes only happening occasionally. (Otherwise, if concurrent
access is indeed the cause of the crashes, I do not understand why
they happen only very occasionally.)
It would be very helpful and much appreciated if one of our friends
on Apple's PDFKit team could confirm/negate/shed some light on this
last statement.
Thanks,
António
-----------------------------------------------------------
And you would accept the seasons of your
heart, even as you have always accepted
the seasons that pass over your field.
--Kahlil Gibran
-----------------------------------------------------------
_______________________________________________
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