Steve,
To answer your question: no, we're not removing -XstartOnFirstThread
from the JDK. We just no longer check this flag when initializing AWT
because it can be initialized either way. Note, however, that AWT
expects that the SWT is already running its event loop when AWT is
starting up on the main thread. If it's not true, then AWT will start
its own loop and therefore block the main thread for the code that
caused the AWT to start up on the main thread in the first place. I
think this situation is unlikely to occur though, but there's simply not
a better solution because AWT requires a native event loop, and it can't
be sure if someone else is going to start it later on.
--
best regards,
Anthony
On 1/11/2013 17:37, Petr Pchelko wrote:
Hello, Steve.
You've asked for a code sample. Sorry for the delay, here is it.
If you close SWT window first - AWT hangs.
With best regards. Petr.
------------------------------------------------------------------------
On Jan 10, 2013, at 9:06 PM, [email protected] wrote:
Hi all,
I'm a little out of the loop with respect to what is going on here. Please
bear with me.
First off, we are not removing -XstartOnFirstThread from the JDK, correct? SWT
does not expect other event loops or toolkits to be running. Like a native
application, it expects to be able to run an event loop in main(). The
-XstartOnFirstThread forces Java main() to be the same thread C main(), which
is the Cocoa GUI thread.
Can you attach the example code that is failing so I can see what we are trying
to do?
Steve
On 10/01/2013 11:23 AM, Petr Pchelko wrote:
Hello again.
Sergey wrote:
As far as I understand from the discussion SWT doesn't survive situation, when
we open 2 window(SWT and AWT) and close SWT window first. Since in this case
SWT stops appkit run loop. This fix works in this case and this means that we
should apply the same patch to SWT.
Petr, can you clarify this? Thanks
I have applied the patch and tried a little example with SWT Window and AWT
Frame. The app still hangs in case the SWT Frame is closed first. The problem
is that in SWT the common pattern is to put such code to the end of main:
while (!shell.isDisposed()) {
if (!display.readAndDispatch()) display.sleep();
}
display.dispose();
//end of main function
(It is so common that it is in the first helloworld example in the SWT
documentation)
So, SWT does not care about the native events, it shuts down as soon as Shell
gets disposed. The main thread finishes and AWT hangs.
I don't think we could fix the issue in AWT, but there is a simple workaround
to add a dispose listener to the shell which would spin the runloop until
AWTAutoShutdown.isReadyToShutdown, so it could be fixed in SWT.
However, the case when AWT and SWT windows are opened simultaneously is so
likely to produce deadlocks that I am not sure we want to support this case at
all. JDK6 does not.
As for the embedded case, the issue with shutdown is fixed on the SWT side,
however, making the AWTAutoShutdown method public would allow to make the
solution better.
With best regards. Petr.
This fix actually does not help in the case when SWT
On Jan 10, 2013, at 6:24 PM, Petr Pchelko wrote:
Yes. SWT did not survive in such a situation. A will try to apply the fix and
test if it helps with the SWT.
With best regards. Petr.
On Jan 10, 2013, at 6:13 PM, Sergey Bylokhov wrote:
10.01.2013 17:55, Anthony Petrov wrote:
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.
As far as I understand from the discussion SWT doesn't survive situation, when
we open 2 window(SWT and AWT) and close SWT window first. Since in this case
SWT stops appkit run loop. This fix works in this case and this means that we
should apply the same patch to SWT.
Petr, can you clarify this? Thanks
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
--
Best regards, Sergey.
