The solution is to allocate Cocoa data structures on the AppKit thread,
exclusively, if they need to be deallocated later. More specifically,
since our PDF data is generated on the Java/Swing thread, we put it in
a normal Java byte array, and pass that to the AppKit thread using JNI.
The AppKit thread allocates its own NSData, copies the PDF data into
it, then signals the Swing thread that its copy of the data is no
longer needed. And the AppKit thread releases its own data later.
So we have a duplicated data structure that serves no other purpose
than to prevent the JVM from crashing.
Is this a JVM bug? An AppKit bug? Has anybody else out there had
trouble allocating Cocoa data in the Swing thread and deallocating in
the AppKit thread?
Geoff
On 25 Mar 2005, at 12:26, Geoff Levner wrote:
Greetings!
We have a Swing application that uses an AWT CocoaComponent to display
PDF files.
More specifically, the Java/Swing thread generates the PDF and creates
an NSPDFImageRep, which is transmitted to the AppKit thread via the
CocoaComponent's sendMessage method. The AppKit thread receives the
NSPDFImageRep and displays it in the NSView. And in the Swing thread,
I am careful never to touch the NSPDFImageRep once it has been passed
to the AppKit thread.
Usually this works fine. But occasionally the JVM crashes, apparently
when the AppKit thread releases the old NSPDFImageRep.
Is there something fundamentally wrong with this approach, or is this
a bug? If anybody can suggest a better way to do this, I would
appreciate it...
Thanks in advance,
Geoff
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
