Steve wrote:
> SWT applications determine when they need to quit and the pattern that you
> see in the example code (waiting for a single shell to be disposed) is not
> the same pattern than is used by Eclipse and other applications
I understand, but I have took this pattern from the first HelloWorld example in
the SWT documentation. If it is there, than probably some apps could use this
pattern?
> Does closing the Frame using code work? To test this, add a dispose event
> handler to the SWT shell and in the handler, close the AWT frame.
Not really:
- If we simply invoke frame.dispose() from the main thread we get a
deadlock on treeLock.
- If we invokeLater than main thread exits faster than the AWT shuts
down and we get a hang
- the only option is to use something like LWCToolkit.invokeAndWait
which does not block the main thread, but this is not an option as LWCToolkit
is an internal API as I understand
On Jan 11, 2013, at 7:51 PM, [email protected] wrote:
> Comment inline:
>
> On 11/01/2013 7:07 AM, 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.
>
> SWT applications determine when they need to quit and the pattern that you
> see in the example code (waiting for a single shell to be disposed) is not
> the same pattern than is used by Eclipse and other applications. However,
> when a Display is disposed(), events are flushed and it might be possible to
> do something there.
>
> Steve
>
>>
>> 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.
>>>>>>
