atom feed8 messages in net.java.dev.rococoa.usersRe: rococoa video player
FromSent OnAttachments
Greg KellumDec 18, 2009 12:27 pm 
Duncan McGregorDec 18, 2009 1:03 pm 
Greg KellumDec 18, 2009 1:24 pm 
Harald KuhrDec 21, 2009 5:06 am 
Andrew ThompsonDec 21, 2009 8:01 pm 
Brian SchliningDec 21, 2009 9:09 pm 
Harald KuhrDec 22, 2009 5:26 am 
Harald KuhrDec 22, 2009 5:33 am 
Subject:Re: rococoa video player
From:Andrew Thompson (lord@mac.com)
Date:Dec 21, 2009 8:01:46 pm
List:net.java.dev.rococoa.users

I'd like to see that code.

On Dec 21, 2009, at 8:06 AM, Harald Kuhr wrote:

Hi guys,

On 18. des.. 2009, at 22.25, Greg Kellum wrote:

Well, it sounds like I might need to use calls to Thread.join in a few other
places then as well.

Not directly related, but I've been doing some work lately to work around
deadlocks.

First of all, it's important to note that Apple explicitly says you should not
block the EDT against the AppKit (main) thread or the AppKit thread against the
EDT
(http://developer.apple.com/mac/library/documentation/Java/Reference/1.5.0/appledoc/api/com/apple/eawt/CocoaComponent.html),
as this will likely deadlock. My experience, is that you can leave "likely" out.
This goes for all Rococoa/Swing integrations as well.

I've been using a single threaded ExecutorService (Executors.newSingleThread...)
to make sure that my calls into AppKit never blocks the EDT (there might be a
way to call performSelectorOnMainThread without blocking now that could be used
instead). Then I've used a neat hack I found in an old blog
(http://jroller.com/santhosh/date/20050625), to make sure I can make blocking
calls on the EDT while the EDT still processes events. I might submit my code
for inclusion with Rococoa one day if anyone's interested. And of course always
call back to Swing using SwingUtilities.invokeLater.

AndyT (lordpixel - the cat who walks through walls) A little bigger on the inside

(see you later space cowboy, you can't take the sky from me)