Re: [9] Review request for 8159432: [PIT][macosx] StackOverflow in closed/java/awt/Dialog/DialogDeadlock/DialogDeadlockTest
+1 Thanks, Alexander. On 11/1/16 10:59 PM, Sergey Bylokhov wrote: Looks fine. On 05.10.16 11:45, Semyon Sadetsky wrote: To avoid this the 8139218 solution is revisited to manage the focus restore synchronously only if it is possible and send a single asynchronous focus request otherwise. Can you please clarify what is the difference between: tempLost.requestFocusInWindow() which was updated in the fix, and toFocus.requestFocusInWindow() which was not updated. As far as I understand the second case(when the toFocus==restoreFocusTo) is a component to which we should send ROLLBACK. If you look on the comment above the toFocus.requestFocusInWindow() line you get the case when it is called. Actually tempLost.requestFocusInWindow() is the right place to set ROLLBACK. Focus is requested with ROLLBACK cause only when tempLost==toFocus, but it is hard prove, so I'll better to add the condition: http://cr.openjdk.java.net/~ssadetsky/8159432/webrev.01/
Re: [9] Review request for 8159432: [PIT][macosx] StackOverflow in closed/java/awt/Dialog/DialogDeadlock/DialogDeadlockTest
Looks fine. On 05.10.16 11:45, Semyon Sadetsky wrote: To avoid this the 8139218 solution is revisited to manage the focus restore synchronously only if it is possible and send a single asynchronous focus request otherwise. Can you please clarify what is the difference between: tempLost.requestFocusInWindow() which was updated in the fix, and toFocus.requestFocusInWindow() which was not updated. As far as I understand the second case(when the toFocus==restoreFocusTo) is a component to which we should send ROLLBACK. If you look on the comment above the toFocus.requestFocusInWindow() line you get the case when it is called. Actually tempLost.requestFocusInWindow() is the right place to set ROLLBACK. Focus is requested with ROLLBACK cause only when tempLost==toFocus, but it is hard prove, so I'll better to add the condition: http://cr.openjdk.java.net/~ssadetsky/8159432/webrev.01/ -- Best regards, Sergey.
Re: [9] Review request for 8159432: [PIT][macosx] StackOverflow in closed/java/awt/Dialog/DialogDeadlock/DialogDeadlockTest
On 05.10.2016 03:04, Sergey Bylokhov wrote: On 24.08.16 22:18, Semyon Sadetsky wrote: The issue is connected to the restoring focus to the previously focused window when there are a lot of focus restore requests are coming very often (for example series of windows showing and hiding quickly). In this case waiting for asynchronous focus causes nested waiting loop, and if number of such requests is big enough the StackOverflowError is thrown. To avoid this the 8139218 solution is revisited to manage the focus restore synchronously only if it is possible and send a single asynchronous focus request otherwise. Can you please clarify what is the difference between: tempLost.requestFocusInWindow() which was updated in the fix, and toFocus.requestFocusInWindow() which was not updated. As far as I understand the second case(when the toFocus==restoreFocusTo) is a component to which we should send ROLLBACK. If you look on the comment above the toFocus.requestFocusInWindow() line you get the case when it is called. Actually tempLost.requestFocusInWindow() is the right place to set ROLLBACK. Focus is requested with ROLLBACK cause only when tempLost==toFocus, but it is hard prove, so I'll better to add the condition: http://cr.openjdk.java.net/~ssadetsky/8159432/webrev.01/
Re: [9] Review request for 8159432: [PIT][macosx] StackOverflow in closed/java/awt/Dialog/DialogDeadlock/DialogDeadlockTest
On 24.08.16 22:18, Semyon Sadetsky wrote: The issue is connected to the restoring focus to the previously focused window when there are a lot of focus restore requests are coming very often (for example series of windows showing and hiding quickly). In this case waiting for asynchronous focus causes nested waiting loop, and if number of such requests is big enough the StackOverflowError is thrown. To avoid this the 8139218 solution is revisited to manage the focus restore synchronously only if it is possible and send a single asynchronous focus request otherwise. Can you please clarify what is the difference between: tempLost.requestFocusInWindow() which was updated in the fix, and toFocus.requestFocusInWindow() which was not updated. As far as I understand the second case(when the toFocus==restoreFocusTo) is a component to which we should send ROLLBACK. -- Best regards, Sergey.
Re: [9] Review request for 8159432: [PIT][macosx] StackOverflow in closed/java/awt/Dialog/DialogDeadlock/DialogDeadlockTest
looks good to me. -- Thanks, Alexander. On 24.08.2016 22:18, Semyon Sadetsky wrote: Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8159432 webrev: http://cr.openjdk.java.net/~ssadetsky/8159432/webrev.00/ The issue is connected to the restoring focus to the previously focused window when there are a lot of focus restore requests are coming very often (for example series of windows showing and hiding quickly). In this case waiting for asynchronous focus causes nested waiting loop, and if number of such requests is big enough the StackOverflowError is thrown. To avoid this the 8139218 solution is revisited to manage the focus restore synchronously only if it is possible and send a single asynchronous focus request otherwise. --Semyon
