Description Christoph Laeubrich 2020-09-08 01:35:46 EDT

One of the most annoying things IMO currently is the "only call from realm concept".

Almost all implementations of the interfaces state that

> This class is thread safe. All state accessing methods must be invoked
> from the {@link Realm#isCurrent() current realm}.
> Methods for adding and removing listeners may be invoked from any thread.

So first of all its a bit hilarious to state a class is thread safe but require most of its methods to be executed inside a (single threaded) realm, even worse the API interfaces do not put such a restriction on the consumer so a user has to KNOW what implementation is used beforehand when accessing such an interface or will be thrown an exception when using this "thread-safe" class in a multi-threaded environment.

This "safety" is currently archived by calling all and everywhere (but not consistently everywhere...) a checkRealm() method that executes an Assert that the realm is the current one.

So in fact to really use an Observable in a possible multi-threade environment and the user can't be sure that its on the real-thread atm the user-code has to be decorated with a myriad a boilerplate-code checking for the realm, execute there, keep track of possible return values to hand over to the outer code and so on.

I'd like to propose a different approach given the fact that the code already does all that checking to take the logical consequence in the following way:

Instead of checkRealm we should add a set of methods to the realm itself that allows to execute a method inside the realm and return a value similar to the current run() method but with one difference: if the current realm is the realm it will be executed directly and if not the method is called in the realm waiting for the result.

Then an implementation can simply call for example to be sure to execute the method inside the realm:

> public X setValueAndReturnSomething() {
>    return getRealm().execute(this::doSetAndGet);
> }

more sophisticated implementations even might embody lock-free methods to update the value atomically and only call the listeners inside the realm.