Skip to content
This repository has been archived by the owner on Mar 17, 2021. It is now read-only.

WIP: Usubscribe from events on the next subscription (PyTango#292) #1095

Closed
wants to merge 3 commits into from

Conversation

reszelaz
Copy link

@reszelaz reszelaz commented Mar 21, 2020

Similarly to #1091 and #1093, this PR tries to workaround tango-controls/pytango#292.

I tried this PR with sardana-org/sardana#1312 ( which reverts the Sardana workaround and use zombie concept in tests) and it works corrrectly for the sardanatestsuite and for the stress macro posted in #1093 (comment). So, IMO it is a satisfactory workaround.

Note that it has one side effect - it keeps garbage collected attributes subscribed until some new attribute is subscribed. To mitigate this effect attributes are marked as zombies - their push event return immediately. Also this should happen only for the configuration events - the change events should be unsubscribed with the last TaurusModel.removeListener call. Also if one wants to increase the frequency of unsubscribes the tangoattribute._empty_unsub_queue() could be called more frequently.

Deposit unsubscription on a queue and execute it on the next subscription.
Meanwhile mark the attribute as zombie - do not process any events
and do not return it by the factory.
This is necessary for Sardana test suite which restart the device server
in between the tests. If the GC does not destroy the TangoDevice on time
for the next test then we receive API_EventTimeout errors which then
enable polling and this situation is hard to control in the tests.
With the zombie flag we mark a TangoDevice as disposable and ask the
factory for a new one.
@reszelaz
Copy link
Author

One could also try to play manually with GC. Something like:

  • call gc.collect() before we subscribe to events. This way we will ensure that there are no pending unsubscribes to be done.
  • disable GC before subscribe and enable it after

(I have not tried neither of them)

@reszelaz
Copy link
Author

reszelaz commented May 7, 2020

The root issue was solved in tango-controls/cppTango#699.
It is available starting from cppTango 9.3.4rc5. Hence I do not foresee to work anymore on this PR.

@reszelaz reszelaz closed this May 7, 2020
@cpascual
Copy link
Member

cpascual commented May 7, 2020

Thanks @reszelaz for taking care of this, and sorry for not having been as responsive as I should (I have been busy in other fronts).

One thing that remains to do is using the cppTango >= 9.3.4rc5 in our CI. This could be one way to try to fix #1042

@cpascual cpascual modified the milestones: Jan20, Jul20 May 7, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants