JDK-6980209 : Make tracking SecondaryLoop.enter/exit methods easier
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7,8,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2010-08-26
  • Updated: 2017-11-29
  • Resolved: 2015-05-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9
8u152Fixed 9 b68Fixed
Related Reports
Relates :  
Relates :  
Description
Here is a code snippet from java.awt.SecondaryLoop JavaDoc:

   SecondaryLoop loop;

   JButton jButton = new JButton("Button");
   jButton.addActionListener(new ActionListener() {
       {@code @Override}
       public void actionPerformed(ActionEvent e) {
           Toolkit tk = Toolkit.getDefaultToolkit();
           EventQueue eq = tk.getSystemEventQueue();
           loop = eq.createSecondaryLoop();

           // Spawn a new thread to do the work
           Thread worker = new WorkerThread();
*          worker.start();

           // Enter the loop to block the current event
           // handler, but leave UI responsive
**         if (!loop.enter()) {
               // Report an error
           }
       }
   });

   class WorkerThread extends Thread {
       {@code @Override}
       public void run() {
           // Perform calculations
           doSomethingUseful();

           // Exit the loop
***        loop.exit();
       }
   }

The code marked with (*) spawns a new thread. Note that (***), which is called on this new thread, can potentially be invoked before the loop is started with (**). This is not a problem in java.awt.Secondary loop, however there's no easy way for developers to detect and resolve this situation.

Comments
There are 2 issues in WaitDispatchSupport: 1. If exit() is called before the secondary loop just silently never ends. That is pointed in the summary. 2. In the same spec it is proposed to call exit() and enter() concurrently but they are not thread-safe. For example: a) "enter" is called on non-dispatch thread b) the thread scheduler suspends it at, say, the point right after "keepBlockingEDT" is set to true (line 177). c) "exit" is called, "keepBlockingEDT" is set to false, "wakingRunnable" is posted to EDT and gets executed on EDT, "keepBlockingCT" is set to false b) "enter" continues execution, "keepBlockingCT" is set to true, getTreeLock().wait() potentially makes the thread sleep endlessly That is an additional issue. To fix 1: I support Artem's proposal for enter() to return false in case if disordered exit() detected. To fix 2: WaitDispatchSupport need to be reworked to allow concurrent execution. Unfortunately we cannot synchronize EDT with another thread, so the secondary loop launching cannot be run atomically. And this is very sensitive area because of potential possibility to block EDT. Right testing of the fix is very desirable.
30-03-2015

- this is an issue reported against 7(7u), - there are now affected version 9 filed for this issue - 7u issues are transferred to Sustaining Nevertheless if someone have a report against 9 - please reopen and add affectedVersion 9 or 7u specific escalations might be reopen to Sustaining
10-08-2014

- this is an issue reported against 7(7u), - there are now affected version 9 filed for this issue - 7u issues are transferred to Sustaining Nevertheless if someone have a report against 9 - please reopen and add affectedVersion 9 or 7u specific escalations might be reopen to Sustaining
10-08-2014

These are all approved for deferral to JDK 9 so you can update the FixVersion to state JDK 9. Kind regards, Mathias
29-08-2013

These are all approved for deferral to JDK 9 so you can update the FixVersion to state JDK 9. Kind regards, Mathias
29-08-2013

These are all approved for deferral to JDK 9 so you can update the FixVersion to state JDK 9. Kind regards, Mathias
29-08-2013

Converted "8-client-defer-candidate" label to "8-defer-request" by SQE' OK.
15-08-2013

*This is anti-deferral criteria list*: - P2 -------------- Engineering's Criteria ------------------------------------- - tck-red labeled - conformance labeled - P3 regressions reported/labeled against jdk8 - findbugs, parfait, eht labeled bugs - CAP <1 year reported - netbeans <1 year reported Victor ----------------- SQE's OK --------------------------------- Yes, we are ok with that thanks, Mikhail
15-08-2013

EVALUATION One of the possible solutions is to track if exit() is called first and make the first subsequent call to enter() return immediately (with "false" as the return value to conform the specification, as the loop is not started).
26-08-2010