<Swing Dev> RFR: 8240690 Race condition between EDT and BasicDirectoryModel.FilesLoader.run0()
Prasanta Sadhukhan
prasanta.sadhukhan at oracle.com
Mon Mar 16 11:55:10 UTC 2020
Looks ok to me.
Regards
Prasanta
On 09-Mar-20 5:17 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk/client.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8240690
> Fix: http://cr.openjdk.java.net/~serb/8240690/webrev.01
>
> The test in the webrev has failed from time to time in our
> CI. It was closed and serialize/deserialize the JFileChooser
> on the main thread under Motif L&F only. Initially, I thought
> that the intermittent issues will be fixed by moving the code
> to EDT. I have done it, and also add a check for all L&Fs.
> As a result, I was able to reproduce tons of issues related
> to JFileChooser on all platforms.
>
> 1. When we create the JFileChooser and initialize some L&F,
> we create some background thread that loads the list of files,
> and only after that adds the list of files to the JFileChooser
> itself. This is one of the exception where we access the swing
> component on non EDT, take a look to the changes in
> BasicDirectoryModel.FilesLoader.
> I have moved some calls to the JFileChooser from the FilesLoader.run0
> which is executed on the background thread to the constructor of
> FilesLoader which is executed on the EDT. So on the background
> thread, the "JFileChooser.isTraversable" and "JFileChooser.accept" will
> be used. These methods are changed to be more multiple-threads
> friendly(mostly read the property to the local field then check, then
> use).
>
> 2. During serialization, we temporarily reset the FileSystemView of
> the JFileChooser to the null(it is also possible to do this via public
> API).
> This uncovered a few places where we did not expect the null.
>
> 3. The "FilesLoader" had a logic of "runnables" blocks of data which
> should be used to update the JFileChooser by some portions of data. We
> used the only one "runnable" in the Vector of runnables, but even then
> it caused a concurrent modification exception if we tried to cancel the
> task and background thread modified the list of tasks(the list from empty
> became non-empty). ->> I just replaced it by one reference.
>
> Note that this fix works only on top of
> https://mail.openjdk.java.net/pipermail/swing-dev/2020-March/010155.html
> otherwise serialization just does not work on macOS.
>
More information about the swing-dev
mailing list