For me the problem is solved, no need to test any more. Nevertheless it would be interesting to know from David what really triggered that problem. To my understanding it had nothing to do with the amount of text in a comment.
Yes and no. The amount only triggered a bug that was already existing but dormant because the amount of text changed the timing of certain operations.
The core problem was that two threads where deadlocking each other. We had the main UI thread (the "AWT" thread) trying to do some painting/animation to a UI component at the same time that a metadata loader thread tried to update it (change its text). I assume that these two threads locked the same UI resources, but in different order, thereby causing a deadlock. I can see a hint of this as they both tried to lock the same "monitor". A monitor is a device that controls unique access to a shared resource. Compare with the occupied/free sign on the toilet of an airplane.
Here's a typical deadlock scenario that's rather intuitive to understand:
Imagine two mechanics (the two threads) working on their own cars, but they share the same tool box (in our case the user interface components are shared). Now imagine that the first mechanic grabs the screwdriver and the second grabs the wrench. All is fine so far. Now imagine that the first mechanic also needs the wrench, so he waits for it to be returned to the tool box. Now imagine the second mechanic (the one holding the wrench) realizing he also needs the screwdriver, so he waits for it to be returned to the tool box. These two mechanics now "deadlock" each other. They will wait forever unless one of them politely "backs out" and returns his tool to retry later.
There are many different ways to handle these scenarios. Either one can have a device that detects deadlock and makes one party back out or one tries to avoid the deadlock to happen altogether. You can for instance avoid shared resources (give each mechanic their own unique tool boxes) or set up a policy dictating in what order shared resources are to be reserved, or dictate that one is to grab and return the whole tool box for every operation, but that hurts concurrency (increases overall waiting time). A forth solution could be for one mechanic to hand over the work involving shared tools to a dedicated mechanic ("Everyone lets Tom change the tyres"). It is this last approach that's dictated by Java's UI framework Swing. In Swing, UI components should only be manipulated from the AWT thread. In an earlier jAlbum 20 beta I was actually loading the file metadata and updating the UI components from the AWT thread, but this was slow as it only utilized one CPU core. Furthermore this made scrolling feel sluggish. I then fixed this to use multiple background threads for reading metadata, but forgot to ensure that they passed the result over to the AWT thread when finally updating the comment text field component for instance.
Before the change, the code looked like this:
Metadata loader thread:
comp.setText(originalText); // Oops, doing this from a background thread is not allowed
The fixed code hands over the updating to the AWT thread like this:
Metadata loader thread:
SwingUtilities.invokeLater(() -> comp.setText(originalText));
I hope you enjoyed this little lecture
. I find multi threaded issues both tricky and fascinating. Tricky because one cannot always reproduce them (they are timing sensitive). Fascinating because we actually encounter and tackle the same kind of problems in our everyday lives, usually even without thinking about it. In the computer world we simply pick among solutions from the real world.
