https://bz.apache.org/bugzilla/show_bug.cgi?id=60687

--- Comment #18 from Philippe Mouawad <[email protected]> ---
(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.

Reply via email to