# Value handling, Threads

When receiving a new value from EPICS Channel Access or whatever network protocol is used, one cannot immediately update the screen with that value:

1. The network library probably uses multiple threads, yet Eclipse UI updates must only happen inside the UI thread.
2. When many new values arrive, tbat can be too much for the GUI.

Currently, each new value is handled as follows:

1. ChannelAccess client library has unknown threads, further wrapped by the PVTable's 'PV' interface (EPICS_V3_PV implementation).
2. PVListModel receives PV value updates, and marks the associated entry as "changed".

3. Periodic PVListModelValueUpdateThread checks if any model entries have changed, and notifies listeners. This layer throttles the updates. Even if multiple value updates arrive for an entry between checks, only one entry update is sent. Up to here, it's all independent of Eclipse APIs

4. The PVTableViewerHelper which interfaces the model with the SWT table in the editor or viewer receives the updates. It uses 'Display.syncExec' to run the table update in the UI thread.
   Used 'syncExec' instead of 'asyn..' because the update thread should wait for the updates to finish, not start new updates in case the current screen redraw is too slow.

Advantage: Separation of network lib, model, UI.

Disadvantage: Too many layers, overall too slow?

- Original Performace: "Editor" table with 99 PVs at 10Hz used 70..75% CPU, and didn't really update at 10Hz.
- Added hash map to resolve arriving PV monitors to the table entry: No change.
- Separated PV model listeners to 'value' from the model 'structure' listeners, so that table editor can only listen to 'structure' changes in order to update the 'dirty' status, but ignore the value updates which are alread handled by the PVTableViewerHelper: 60..70% CPU load, but still not 10Hz display updates.
- Enabled 'setUseHashlookup(true)' for the JFace table viewer (which uses SWT.VIRTUAL with ILazyContentProvider): No visible change, though mapping from model entry to associated SWT widget looks 'faster' in the debugger.

One fundamental issue is the Eclipse Table and TableViewer. In principle, it seems reasonable to only redraw the table cells that actually change dynamically (time, PV, Readback). But any attempts to redraw only those cells, or maybe only the changed table rows turned out to be much slower than a full table refresh.