Re: [eclipse-incubator-e4-dev] Initial discussion onthe'modelled'workben

[Boris Bokowski <Boris_Bokowski@xxxxxxxxxx>]

This is not as easy as it sounds. Making all events asynchronous would make
it hard to read additional model state from listener code. You would have
to start locking objects, potentially leading to deadlocks again.

Furthermore, objects that observe incremental updates of a model need to
get the initial state of the model *and* attach their listener object in
one atomic operation. This is hard in a multi-threaded environment, where
there can be race conditions with the potential to miss updates, or to
receive the same update twice.

As far as I know, EMF does not address this problem - or you could say that
it lets you solve it any way you want. I.e., you either make sure that you
access your model from only one thread, or that you acquire locks before
accessing the model. Ed, please correct me if I am wrong!

For the data binding framework, we settled on a solution where every
observable (read: "model object") can only accessed from within its
"realm", and will also fire events within that "realm". Sounds strange, but
anyone who has used SWT before should recognize the pattern: Being in a
realm can mean being on a certain thread, or it can mean holding a lock.
Think of it as a coarse-grained synchronization mechanism. The standard way
to get code to execute in a realm is by using Realm.asyncExec(runnable).
This should be familiar to anyone who has called Display.asyncExec before -
the SWT display thread is one of those realms.

The question of how to deliver change notifications to observers in a safe
way is orthogonal to the synchronization problem (I hope). You can protect
the framework from ill-behaved listener implementations just as well as you
can protect it from ill-behaved consumers connected to an event bus.

Boris

eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx wrote on 04/07/2008 07:48:00
AM:

>
> It would be a radical change, but you may want to consider making
> all events asynchronous. This would have solved many problems in our
> old API, but was never doable in a backwards compatible way.
> Asynchronous event notification to clients offers lots of advantages
> - reduced deadlock, increased responsiveness, etc. If the UI model
> can be manipulated in any thread, then you may be able to keep
> client code out of the UI thread entirely!
>
> John
>
> eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx wrote on 04/07/2008 06:02:37
AM:
>
> > Hi all,
> >
> > one more thing I think we need to discuss is whether we really want to
> > allow any arbitary plugin register as a listener on our model.
> >
> > This has the drawback that if one missbehaving listener is added to our

> > model everybody is blocked! In a Plugin-Env where we don't control them

> > this a dangerous thing, not?
> >
> > Wouldn't it be wiser to decouple this using a Message-Bus-Pattern? What

> > do you think?_______________________________________________
> eclipse-incubator-e4-dev mailing list
> eclipse-incubator-e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev