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

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

With this scheme, in what realm does
the UI model live? Is it in the same realm as the actual display? If a
client needs to lock part of the UI model in order to obtain guarantees
about its state while it is being manipulated, this doesn't mean the UI
thread itself needs to be locked... I suppose the notion of realms precludes
the possibility of finer-grained locking of the model since all modification
must occur within a single thread. It would be neat if different threads
could lock and modify different parts of the model concurrently - think
of each view updating its own model independently based on some background
processing that's going on.  I don't have a concrete answer, I'm just
pondering aloud.

John

Boris wrote on 04/07/2008 09:08:46 AM:

> 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
> 
> John 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