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.
Main.java
Description: Binary data
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. >>>>
