On Thu, 12 Dec 2019 23:29:11 GMT, Kevin Rushforth <k...@openjdk.org> wrote:
>>> 1. In addition to calling the synchronized `setTKScenePaintListener` >>> method, you moved the call to the beginning of `dispose`. Is there a reason >>> you needed to do this? >> >> This is moved only to make first operation when disposing. However the race >> condition is very rare, but this will just reduce the chances little more. >> >>> 2. Do any of the other listeners or variables that are set in `dispose` >>> have the same problem (i.e., are any of the rest accessed from another >>> thread)? >> >> Other variable do not have a race condition. All are set or accessed on >> JavaFX Application thread. >> There are some other variable (not in dispose()) like entireSceneDirty, >> painting, which are accessed on both threads but those are synchronized >> access. > >> This is moved only to make first operation when disposing. However the race >> condition is very rare, but this will just reduce the chances little more. > > Can you elaborate? Why would there still be a race condition? > Can you elaborate? Why would there still be a race condition? Hi Kevin, Looks like I made a confusing statement. There won't be a race condition after this change but there can be a situation when `frameRendered()` gets executed while `dispose()` is in progress. Consider scenario: 1. `dispose()` is called on Application thread, and `setTKScenePaintListener(null)` is not executed yet. 2. `frameRendered()` is called on Renderer thread, and it will find that scenePaintListener is not null and `scenePaintListener.frameRendered()` call will be executed. 3. Then `dispose()` executes `setTKScenePaintListener(null)` If `setTKScenePaintListener(null)` is the first operation in 'dispose()' then chances of above situation reduce little more. However the situation is very rare. This is to make it more sure that `scenePaintListener.frameRendered()` does not get executed once `dispose()` has begun. ------------- PR: https://git.openjdk.java.net/jfx/pull/64
