search

ossgang / ossgang-commons

Apache License 2.0
4 stars 0 forks source link

First update to happen on the dispatcher pool #42

Open andreacalia opened 4 years ago

andreacalia commented 4 years ago

At the moment if you subscribe to an Observable with first update option, the Observer#onValue method is called immediately before the #subscribe method finishes. This behaviour is correct but the listener code is run on the calling thread of the subscribe. This is a side effect that the user has to know and can be sometime problematic (maybe subscriptions are started in the constructor of the class in the GUI thread or, even worst, the Observer#onValue throws and, potentially, kills the caller thread).

I was just wondering if we could improve this by executing the first update call on the same dispatcher pool of the Observable so that it is consistent with the, future, updates of the stream of data :slightly_smiling_face: . If we do this, we have to, willingly, block the caller thread until this is done so the correct behaviour mentioned above is kept.

What do you think? @michi42 @kaifox It is not urgent I just wanted to document it on an issue so we don't forget about it hahaha

https://github.com/ossgang/ossgang-commons/blob/848de098d0bd279c6709e426c35da5df805c4991/src/main/java/org/ossgang/commons/observables/DispatchingObservableValue.java#L49-L54

michi42 commented 4 years ago

At the moment, this is exactly the documented behavior: https://github.com/ossgang/ossgang-commons/blob/848de098d0bd279c6709e426c35da5df805c4991/src/main/java/org/ossgang/commons/observables/SubscriptionOptions.java#L10-L15 But I'm fine with changing, as long as the guarantee that the update is delivered before subscribe() returns is kept.

Anyway, even if we keep the behavior of dispatching from the subscribing thread, we should at least catch and deflect the exception.

andreacalia commented 4 years ago

Exactly :smile: I think we have to keep the functionality