StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>I can confirm that we successfully run SWT <strong>Carbon</strong> on Mac OS X in its own event loop kicked off by a bundle activation, so it's definitely possible! This is using -XstartOnFirstThread when launching the VM.</p> <p><strong>But</strong>, with Cocoa SWT (64-bit), I see the same error :(</p> <p>It seems that, although the way we ran Carbon SWT worked, it was probably not kosher: we were driving the event loop through another thread, not the main one as you're supposed to. Under Cocoa SWT, this doesn't work any more, and it was probably dodgy practice anyway.</p> <p>I can fix the thread pool errors with the following hack before creating the Display (adapted from the Cocoa SWT Device constructor):</p> <pre><code> NSAutoreleasePool pool = (NSAutoreleasePool) new NSAutoreleasePool().alloc().init(); NSThread nsthread = NSThread.currentThread(); NSMutableDictionary dictionary = nsthread.threadDictionary(); NSString key = NSString.stringWith("SWT_NSAutoreleasePool"); id obj = dictionary.objectForKey(key); if (obj == null) { NSNumber nsnumber = NSNumber.numberWithInteger(pool.id); dictionary.setObject(nsnumber, key); } else { pool.release(); } </code></pre> <p>However, the event loop that follows hangs (i.e. the display.readAndDispatch ()/display.sleep () dance). I suspect it's just not reading UI events due not being the main thread.</p> <p>I'm not sure if there's a kosher way to fix this. In my case, we control the main JVM thread that launches OSGi, so I'm toying with the idea of adding a hook in there that can run the SWT event loop after OSGi launch.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload