I had those hangs in previous (not public) versions, and they were quite "logical" : the GUI-thread was waiting for the checker thread and vice versa. I initially thought a similar thing was happening here, but it can't :
The first 2 lines are output from the GUI-thread. The first line is the last output from initializing the tracksection already on screen when you start the application. The second line shows you have just clicked the mouse once and tries to check the tracksection between your first click and the current mouse position. Because you have not actually clicked the mouse, the "wait" signal is false, which means the GUI thread will move on, without waiting for the result.zuu wrote:just before return : (33,219) - (17,219) valid = true
newCheck : (50,50) - (50,50) wait = false visible = true
start checking (50,50) - (50,50)
newCheck : (50,50) - (47,45) wait = false visible = true
The third line is the checkerthread, starting to check the first work it has received.
The last line is the GUI signalling a new tracksection to check.
Those 2 threads should not be waiting for anything at this time (or atleast not untill some other output comes to the screen).
I have 3 possible causes :
1) I don't have all output that should be generated by this time. This could be because of a different implementation of System.out.println() in Java for linux.
2) I do use some locks in the code, but I always lock the objects in the same order, so deadlocks should not occur. Maybe Java for linux doesn't take this ordering as strict as it does on windows.
3) I can't find a logical error.
I do hope it's number 1. I'm now working on a version with a little more debug info (about locks etc), that uses a log.txt file instead of the screen.