Hi Przemyslaw, Thanks for bringing up the topic. A long time ago we had similar topic, I agree that the way it works now is not good at all, because it leads to a lot of problems, I remember the time when our tests were randomly broken because of deadlocks and race conditions with fake thread.
We should write some helpers for receiver module, to explicitly and easily change state of the system, as you mentioned it should be done in synchronous fashion. But of course we cannot just remove fake and we should continue supporting it, some fake thread specific tests should be added to make sure that it's not broken. Thanks, On Mon, Feb 16, 2015 at 2:54 PM, Przemyslaw Kaminski <pkamin...@mirantis.com > wrote: > Hello, > > This somehow relates to : in integration tests we have a class > called FakeThread. It is responsible for spawning threads to simulate > asynchronous tasks in fake env. In BaseIntegrationTest class we have a > method called _wait_for_threads that waits for all fake threads to > terminate. > > In my understanding what these things actually do is that they just > simulate Astute's responses. I'm thinking if this could be replaced by > a better solution, I just want to start a discussion on the topic. > > My suggestion is to get rid of all this stuff and implement a > predictable solution: something along promises or coroutines that > would execute synchronously. With either promises or coroutines we > could simulate tasks responses any way we want without the need to > wait using unpredictable stuff like sleeping, threading and such. No > need for waiting or killing threads. It would hopefully make our tests > easier to debug and get rid of the random errors that are sometimes > getting into our master branch. > > P. > >  https://bugs.launchpad.net/fuel/+bug/1421599 > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev