<AWT Dev> [8] Review request for 8005465: [macosx] Evaluate if checking for the -XstartOnFirstThread is still needed in awt.m

[Sergey Bylokhov]

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<anthony.petrov at oracle.com>  
>>>>>>>> написал(а):
>>>>>>>>
>>>>>>>>> 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.