Modifying sessionManager from an observer may cause observers seeing events in different order and other "in-between states"

[pocmo]

For #379 I added code in the sample browser that will add a new tab if all tabs get closed. However this code is indirectly called from a session manager observer. If there are more observers then the following ones would get called with the session manager state already changed - or other calls in between.

Let's say there are two observers (A / B) registered on the session manager. And the session manager has one session X.

• session manager (X)
• X is removed from session manager.
• A.onSessionRemoved(X) gets called: A adds a new session Y to session manager and this will notify observers:
  • A.onSessionAdded(Y) gets called
  • B.onSessionAdded(Y) gets called
• B.onSessionRemoved(X) gets called.

In the end A and B have observed the same events. But in different order. B never saw an empty session manager:

• For A: (X) -> () -> (Y)
• For B: (X) -> (X,Y) -> (X)

┆Issue is synchronized with this Jira Task

[pocmo]

I wonder what a good solution to that is.

The only solution I can come up with is that all modifying methods are not executed synchronously but on a single-threaded executor. With that modifications during a dispatch would just be queued until the current update is made and dispatched to all observers.

[csadilek]

I think we run into this because we're using an reentrant lock (synchronized(observers)) in our ObserverRegistry.notifyObservers. So, when notifying one observer that notifies more, those subsequent calls can enter and execute right away (before the original observers are notified.) If we used a semaphore/mutex instead those calls would instead have to wait until all observers are executed. I think with this change we could still execute them synchronously which is simpler than introducing a thread/queue?

[pocmo]

If we used a semaphore/mutex instead those calls would instead have to wait until all observers are executed.

Wouldn't we deadlock then? It's the same thread that is notifying observers and then modifying sessionManager?

[csadilek]

Wouldn't we deadlock then? It's the same thread that is notifying observers and then modifying sessionManager?

Yes, we can't block on the mutex. I was mainly trying to look for a synchronous solution. Here's what I was thinking re: mutex/semaphore (tryAcquire doesn't block):

private val notifyMutex = Semaphore(1)
private val queue = LinkedList<T.() -> Unit>()
...
override fun notifyObservers(block: T.() -> Unit) {
        if (notifyMutex.tryAcquire()) {
            observers.forEach {
                it.block()
            }
            notifyMutex.release()

            if (queue.isNotEmpty()) {
                notifyObservers(queue.pop())
            }
        } else {
            queue.push(block)
        }
    }

Would need to try this. Am I missing something?

[pocmo]

We would need to not only prevent the notification of the observers but also the change of the Session properties. Otherwise some observers will get an already modified session object.

[csadilek]

So, I was just focusing on making sure observers see consistent event ordering. I am not sure we need to prevent any (session manager) side-effects in observers until they've all run...

[csadilek]

...but then again, it seems the same pattern could work for SessionManager as well. We'd queue up all changes that happen while its notifying its observers, and apply after. Observers could have all kinds of other side-effects though e.g. they could change sessions directly...

[pocmo]

Assigned myself to sketch something.