Hi, Anthony.
In general the fix looks fine to me. I doubt about stability of this
approach with additional thread.
I advise to verify it on swt before backport to jdk 7.
11.01.2013 16:49, Anthony Petrov wrote:
Petr: thanks for the confirmation.
Sergey: together with the below comments, are you OK with my fix?
AWT folk: can I get at least one more review for this fix please? We
consider porting it to a 7 update release soon, so your prompt reviews
would be very much appreciated.
For your convenience:
http://cr.openjdk.java.net/~anthony/8-52-startOnFirstThreadCheck-8005465.0/
--
best regards,
Anthony
On 1/11/2013 16:07, Petr Pchelko wrote:
Anthony wrote:
OK. So let me get it straight: it didn't work before with SWT, and
for now it's not going to work even with my fix? But my fix itself
does not worsen things up when running with SWT anyway, right? Is
this all correct?
Yes. That all is completely true.
No, why? We don't want to export AWTAutoShutdown. Now that AWT will
send keep alive pings after my fix, SWT, if they want to, could
simply listen to these pings (using the run loop observers), and
return false from the shell.isDisposed() at least for 1 second after
the last keep-alive ping. This will enable both SWT and AWT to
co-exist, prevent any hangs, and allow both of them to terminate w/o
problems when both are finished.
Yes. This solution is much better than what I was thinking about.
With best regards. Petr.
On Jan 11, 2013, at 3:57 PM, Anthony Petrov wrote:
On 1/10/2013 20:23, Petr Pchelko wrote:
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.
OK. So let me get it straight: it didn't work before with SWT, and
for now it's not going to work even with my fix? But my fix itself
does not worsen things up when running with SWT anyway, right? Is
this all correct?
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.
No, why? We don't want to export AWTAutoShutdown. Now that AWT will
send keep alive pings after my fix, SWT, if they want to, could
simply listen to these pings (using the run loop observers), and
return false from the shell.isDisposed() at least for 1 second after
the last keep-alive ping. This will enable both SWT and AWT to
co-exist, prevent any hangs, and allow both of them to terminate w/o
problems when both are finished.
But this is unrelated to the AWT side of things. This is a possible
enhancement for the SWT itself.
--
best regards,
Anthony
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.
--
Best regards, Sergey.
