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

[Anthony Petrov]

On 01/14/13 14:47, Artem Ananiev wrote:
> On 1/11/2013 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?
>
> The described scenario, when we have an SWT shell and an AWT frame and
> then close the shell, didn't work before your fix and won't work with
> the fix applied. Therefore I don't think this workaround with
> AWTKeepAlive daemon thread should be applied. It looks like a hack (and
> is a hack) and doesn't add any value.

We need this for FX+AWT integration. My goal is to ensure that whether a 
user closes an AWT or FX window first, the app won't crash or exit 
prematurely. W/o the AWTKeepAlive the app will crash if I close the FX 
window first (in case AWT is embedded into FX). I believe that we 
shouldn't crash, and hence the solution with keep-alive pings.


> When we eventually decide to support this scenario, and if SWT team is
> ready to listen to AWT "is alive" status, then we'll implement it in a
> clearer way, for example by making AWTAutoShutdown public.

I disagree. This requires an embedder (FX) to know exactly what toolkit 
is embedded into it, e.g. AWT, and hence use the AWT API to see if it's 
still alive. SWT would have to provide similar API, and again, FX would 
have to know that the embedded client is using SWT and use their API. I 
consider this a bad idea.

The keep-alive pings strategy is toolkit-agnostic and allows FX to not 
know what exact GUI toolkit is embedded into it, as long as it sends the 
pings. With my fix we improve the situation when AWT is embedded into 
FX. SWT could improve this use case as well if they want to. But at 
least my fix doesn't do anything worse than it was before.

--
best regards,
Anthony

>
> Thanks,
>
> Artem
>
>>> 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.
>>>>>
>>>