Thanks Petr. I think we don't want to do the same in FX because we don't
even want to call any AWT APIs from there in the first place. Instead,
my current solution offers a way to terminate both toolkits graciously.
Sergey, does this resolve your concern?
--
best regards,
Anthony
On 12/28/12 23:06, Petr Pchelko wrote:
Hello.
As I understood while implementing the EmbeddedFrame, when we embed AWT into
SWT, SWT did not care if AWT is OK to terminate, SWT just called dispose() for
a frame and terminated without looking at AWT. This resulted in issues when AWT
was still terminating but the main SWT thread was already finished. When AWT
was calling something to synchronously perform selectors on the main thread
deadlocks occurred. So we had to add a dispose listener to the SWT container,
which spinned the main runloop until AWT frame finished disposing.
However, I may have misunderstood something.
With best regards, Petr.
28.12.2012, в 20:58, Anthony Petrov<[email protected]> написал(а):
On 12/28/2012 20:36, Sergey Bylokhov wrote:
http://cr.openjdk.java.net/~anthony/8-52-startOnFirstThreadCheck-8005465.0/
2. Introducing an AWTKeepAlive thread activated in the embedded mode only. This
thread will send an event to the native event queue every 500ms as long as
there are active AWT objects present. This activity will notify the embedder
toolkit that the Java application as a whole is still alive and needs not exit
yet.
Why it wasn't necessary for awt-swt bridge?
I don't know. Perhaps we should ask someone who's familiar with SWT? Steve? How
does SWT determine that AWT is dead and therefore it's OK to terminate the
native event loop and exit on the Mac?
--
best regards,
Anthony
