I tried the "min poll period" feature (see https://tango-controls.readthedocs.io/en/latest/Explanation/polling.html#configuring-what-has-to-be-polled-and-how) as a possible solution to problems caused by random polling reconfiguration. It turns out to work (though I tried only for an attribute) but not quite as I had expected, and I see a potential for problems. After setting the `attr_min_poll_period` to e.g. `["ampli", "1000"]` and trying to lower the polling to less than 1000 using a device proxy, I get an exception with a helpful message: `Polling period for attribute ampli is below the min authorized (1000)`. This makes sense. But this check only applies to programmatic changes. If I would change the `polled_attr` property directly, or raise the `attr_min_poll_period` setting to a higher value than the current polling period, nothing will happen until the device is restarted, at which point it crashes: ``` $ /usr/lib/tango/TangoTest test Tango exception Severity = ERROR Error reason = API_MethodArgument Desc : Polling period for attribute ampli is below the min authorized (1000) Origin : void Tango::DServer::check_upd_authorized(Tango::DeviceImpl*, int, Tango::PollObjType, const std::string&) at (./lib/cpp/src/server/dserverpoll.cpp:2162) Tango exception Severity = ERROR Error reason = API_BadConfigurationProperty Desc : Error when configuring polling for device sys/tg_test/1, attr = ampli Origin : void Tango::Util::polling_configure() at (./lib/cpp/src/server/utils_polling.cpp:340) Received a CORBA_Exception Exiting terminate called after throwing an instance of 'CORBA::OBJECT_NOT_EXIST' Aborted (core dumped) ``` The error message is the same but this is not very helpful when running the device with e.g. Astor. Perhaps this is intentional, and a reasonable way to handle this, but even so I think it makes the feature somewhat risky to use. A mistaken configuration can render the device unable to start, which is bad because it means an average user probably won't be able to figure out why. An alternative way might be for the min poll period to be used as a "floor" value, and any period set lower than that will result in an actual polling period of the minimum value. E.g. period set to 500, minimum set to 1000 -> actual polling at 1000. That could also be confusing, but at least it would not prevent the device server from starting. It could still be an error to set the polling period lower via the API as it is today. Perhaps the polling status message could be extended to mention settings that are below the minimum? From the last kernel meeting it appears that this feature is pretty obscure and possibly nobody is using it anyway. In that case it could also be considered for removal, if we don't think it's worth improving.