RFR: 8271395: Fixing crash at printing [v2]

[Kevin Rushforth]

On Wed, 8 Sep 2021 07:52:31 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> This PR switches the Thread to the QuantumRenderer, in the case the Disposer is called from another Thread - the printing Thread.
>> I'm open for better solutions on how to fix this Issue.
>> Initially i thought there is also a Race Condition in the resource pool, but a new one is created for the Printing Thread.
>
> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8271395
>   QuantumRenderer is no longer public

Inline

modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 451:

> 449:         try {
> 450:             CountDownLatch latch = new CountDownLatch(1);
> 451:             com.sun.javafx.tk.quantum.QuantumRenderer.getInstance().execute(() -> {

Minor: this is in the same package, so you don't need the full package name. As long as you are making other changes, you might change this, too.

A bigger question is that I think this is the first time we've used execute directly. I'm not sure that's a problem, but want to take a second look at it. The other places where we run a job on the renderer all use `Toolkit.getToolkit(). addRenderJob()`, which ultimately calls `submit()`.

modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 453:

> 451:             com.sun.javafx.tk.quantum.QuantumRenderer.getInstance().execute(() -> {
> 452:                 runnable.run();
> 453:                 latch.countDown();

If you do stick with the current approach, you would need a try / finally here, to avoid blocking the caller indefinitely. But in that case the exception isn't thrown back to the caller. I think using the existing method that returns a Future might be better.

-------------

PR: https://git.openjdk.org/jfx/pull/618