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.
>>>>
