taurus-tango consider switch to event poll

[tiagocoutinho]

I am sorry in advance for the text format of this issue. It is a quick dump of thoughts and experiments concerning an alternative approach to taurus-tango event handling.

It is the result of discussion between me, @cpascual, @cmft and @reszelaz. Thanks to @jordiandreu for the inspiration!

Currently, taurus-tango plugin registers for attribute events in what tango calls "push" mode. In this mode you register a callback function which gets called for every event.

The taurus implementation at some level suffers from a callback hell syndrome. Also taurus applications tend to be CPU intensive because each widget needs to react to every individual event.

Tango also supports a mode which is called "poll". I completely forgot about this mode until recently when @jordiandreu made me think about it. In this mode you subscribe to an event and it is up to you to ask/consume the list of events that have arrived until that point in time.

I believe this "poll" mode fits more the taurus approach because taurus is a UI library and UI apps are bound to maximum human perception of real time visual feedback (lets say in the range of 10-50 Hz) (games excluded :-).

Most taurus widgets only care about the last event. If an attribute is sending events at 1kHz, a taurus label does not need to process all of them. A label could receive events in bulk mode at a fixed low frequency (ex 10Hz should be completely acceptable). For each bulk of events it could discard all except the last and update the text according to this one. This ensures a responsive feedback while keeping the CPU and Qt signal queue under control.

Taurus widgets which cannot afford to discard events (like taurus trends) could instead receive the events in bulk mode at the same fixed frequency and update their visual interface in blocks of values. So, these widgets could also benefit greatly from this approach.

I attach a pure Qt and PyTango example as proof of concept.

Hopefully there will be time it the future to make a taurus prototype

qt_tango_event_poll.py.tar.gz

[cpascual]

I love the idea!

Here are a few considerations to keep in mind for when we try this with taurus:

• we probably would need to treat the different types of attributes separately: e.g. , a label receiving a bulk of events can happily discard all-but-last event, but only if we are talking about Change or Periodic events, not if we are talking about Error or Config events.

• a final implementation should ideally be transparent, to the point that we can switch it in the same way we switch between "CONCURRENT", "SERIAL" and "TANGO_SERIAL" event modes.

• A final implementation should not impose backwards incompatibilities for widgets. For example, by default, all events should still arrive to the handleEvent() method of the widgets (while still allowing to tap into a more efficient handleEvents() method in new implementations)