Possible deadlock in FilterOnObservable()

[oysteinkrog]

In our (large) application we have a rare deadlock condition in FilterOnObservable(). I am the author of this operator, and I've tried to analyze it and find the source of this, but I currently not making any progress. I'm making this issue as a placeholder for future information, and to see if anyone else has experienced deadlocks when using this operator.

[ins0mniaque]

It might not be related, but in our (also large) application, I've experienced a rare deadlock using AutoRefreshOnObservable. I think it might be related to receiving multiple updates for the same item while it's "initializing". I also have not made any progress debugging it, but adding .Throttle ( ) to our reevaluator "fixed" the deadlock.

[oysteinkrog]

I've been researching this, and honestly it feels like it's a bit above my level of understanding. So far I've been able to work around this by adding an ObserveOn to the reevaluation/filter observable, I suspect your Throttle does a similar job since Throttle schedules on the default scheduler. In the stack traces/parallel stacks views I have going I've seen deadlocks in two different kind of situations;

1. Deadlock w/threads that contain asynclock inside RX.
2. Deadlock w/threads that contain Lazy evaluator lock inside SourceList, on _countChanged field. I was able to resolve both situations with the above mentioned ObserveOn, but it feels like a hack, partially because I don't fully understand the situation. I was able to resolve 2 by modifying DynamicData SourceList (initialize the _countChanged Lazy w/ isThreadSafe:false).

[lippling]

I have the same problem. FilterOnObservable() deadlocks and I don't have any idea why.

[RolandPheasant]

Has anyone been able to replicate this?

[lippling]

No, sorry. We removed the feature which depended on FilterOnObservable() because of the threading issue.

[RolandPheasant]

I personally think FilterOnObservable is not necessarily the best operator as many issues relating to it have been reported, and it is inherently poor performing.

I'd be interested to know what different use cases there are for it and whether alternative specialisations which may be provided.

Also I am considering adding an Obsolete flag to the operator and advise people not to use it,

[RolandPheasant]

There's been a fair degree of work on this operator since this issue was raise so I am closing it. If more issue aries please open a new report preferable with a replication.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.