[prev in list] [next in list] [prev in thread] [next in thread] 

List:       e-lang
Subject:    [e-lang] Q: what are problems with passing mutable objects between local vats?
From:       Constantine Plotnikov <cap () novosoft ! ru>
Date:       2002-10-07 18:32:55
[Download RAW message or body]

What are problems with passing mutable objects between local vats?
If it were allowed for all some parts of integration would be greatly
simplified. As I understand it is currently possible in boot com system,
but it is considered a security risk. I want to understand why this
is an security risk.

I currently see only one unsolvable problem. It creates source of
observable non determinism. And as I understand such sources are wanted
to be completly controled, for some purposes. I believe that there
will be many other sources of nondereminism,  particutlary
in gui apps. Iterating hastables with object key could other
source after deserialization (this will particulary big problem
if iteration is spread among vat turns). So I do not see it as big problem,
and I want hear why it it is considered important.

Also if at least some components will be allowed to perfom
intervat communition with mutable objects (via BootCommSystem)
whole app will loose property of nondeterminism.

Other possible problem is understandability of source code.
As after passing object, it could be changed in other vat,
So there vat will observe changes that had not been made
by it and could not make assumptions about it.

The second problem could be reduced by explicit annotations.
So such changes will not be unexpected. For example method
could declare "local" guard on argument, which will tell that this
argument is expected w/o conversion and "aslocal"  suffix
operation that wrap it. Method with local guard will be called
only if both argument guard local specied and argumen is wrapped
in local "shuttle".

so method will look like.

def MyStream : OutputStream
{
   to write(buf:(DataBuffer & local)):int
  {
     ....
  }
}

and call will be like:

written = stream<-write(buf aslocal)

Such mutable objects could be shared with advisory locking
or other application specific mechanism.

For example for streams, there will be no explicit locking, but
convention that after passing buffer to stream sender will not write
to buffer until promise will be resolved and stream will write to
buffer after it will resolve promise.

Constantine


_______________________________________________
e-lang mailing list
e-lang@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang
[prev in list] [next in list] [prev in thread] [next in thread]