On Wed, 11 Dec 2019 17:10:37 GMT, Ambarish Rapte <ara...@openjdk.org> wrote:
>> The change looks OK as far as it goes, meaning that it will fix the specific >> NPE reported by the bug and is looks like a safe fix. >> >> Two questions: >> >> 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? >> 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)? > >> 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? ------------- PR: https://git.openjdk.java.net/jfx/pull/64
