https://bz.apache.org/bugzilla/show_bug.cgi?id=60687
--- Comment #18 from Philippe Mouawad <p.moua...@ubik-ingenierie.com> --- (In reply to Vladimir Sitnikov from comment #16) > Felix> Could you be a bit more specific here? > > For instance, > 1) Things like "model.insertRow" do require to be executed on the AWT thread. Indeed, good catch. Particularly knowing that insertRow calls fireTableRowsInserted. Can't we just collect rows in a list and insert in model from Timer ? But it will take more time. > I'm not sure how hard it could break, however accessing UI thread on the hot > path is bad. > > 2) Table rendering code (that is run on the UI thread) accesses computed > values without any synchronization. This might result in word tearing, stale > values, unexpected division by zero, etc. > > > Felix> Right. Get swing out of the path and be happy. > > This kind of change would likely to heal 1 above, however it might look like > a "complete rewrite of the relevant listener code". > > Even if we move swing calls out of hot path, we would still need some fast > way to aggregate values. > For instance, "Total" row could be computed "on UI refresh" to avoid global > synchronization of all the threads. > > From one point of view this might look like a over engineering, on the other > hand, that might be reused for "non-gui console mode" listeners. So this means we have a blocker for 3.2 now. -- You are receiving this mail because: You are the assignee for the bug.