On Wed, 5 Mar 2025 15:47:30 GMT, Andy Goryachev <ango...@openjdk.org> wrote:
>> Yes, using a custom property, or a wrapper, would solve this particular >> synchronization problem, although that wouldn't solve all of the problems. >> >> We would then be left with the problem that if the accessibility change >> listener did fire -- which necessarily happens on the FX app thread -- while >> the object was being set up on a background thread, the listener might try >> to modify properties that are being touched on the background thread. This >> is just another case of a more general problem we already have with >> animation, and which Andy fixed by not starting animation in a few places >> unless and until we are on the FX app thread. >> >> So I think the solution Andy has chosen of deferring adding the listener is >> better than trying to fix the accessibility property, followed by fixing the >> listeners that use it, to be thread-safe. > > Thank you, @kevinrushforth . > > Getting back to the rule of allowing Node construction from a background > thread but not "use", should we consider enforcing the thread access rules > for global and static objects (like Platform properties)? > > In other words, constructing objects that might modify internal properties is > ok, but trying to access shared objects is not? > > (maybe it's time to move the discussion out of this PR into the mailing list > perhaps?) Enforcing the threading restriction when using properties is a larger conversation. If we want to have it, I agree it should be on the mailing list. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1697#discussion_r1981874992
