https://bz.apache.org/bugzilla/show_bug.cgi?id=60687
--- Comment #18 from Philippe Mouawad ---
(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.