8 messages in net.java.dev.rococoa.usersRe: rococoa video player| From | Sent On | Attachments |
|---|---|---|
| Greg Kellum | Dec 18, 2009 12:27 pm | |
| Duncan McGregor | Dec 18, 2009 1:03 pm | |
| Greg Kellum | Dec 18, 2009 1:24 pm | |
| Harald Kuhr | Dec 21, 2009 5:06 am | |
| Andrew Thompson | Dec 21, 2009 8:01 pm | |
| Brian Schlining | Dec 21, 2009 9:09 pm | |
| Harald Kuhr | Dec 22, 2009 5:26 am | |
| Harald Kuhr | Dec 22, 2009 5:33 am |
| Subject: | Re: rococoa video player | |
|---|---|---|
| From: | Harald Kuhr (hara...@gmail.com) | |
| Date: | Dec 21, 2009 5:06:02 am | |
| List: | net.java.dev.rococoa.users | |
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.
Good luck!
-- Harald K