| 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: | 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)





