[Fresco-devel] Re: [eros-arch] Fresco?

[adding CC to the Fresco list, in case anyone there wants to jump in.
For those joining the party late, the thread starts at
  http://www.eros-os.org/pipermail/eros-arch/2002-December/003626.html
]

On Thu, Dec 26, 2002 at 01:12:36PM -0500, Jonathan S. Shapiro wrote:
> On Sun, 2002-12-22 at 12:47, C Y wrote:
> > I suppose this is a silly question but is there any chance of the
> > GGI/Fresco project being usable on an EROS system?  It is much more
> > general in nature than PicoGUI.
> 
> So I went off and looked at the Fresco site. I'm really glad to see that
> Interviews has been picked up by somebody.
> 
> That said, I have two concerns about Fresco. The first is that it isn't
> stable yet. Depending on how their progress continues this could turn
> out to be truly minor.

This is true, and in the past, progress has unfortunately been quite
slow -- mostly due to a lack of manpower, but also due to the desire
to do things Right, or at least Better.  On the other hand,
development _has_ picked up quite a bit recently, as a result of some
new developers submitting patches and some organizational changes; I'm
hopeful that this will continue.  As usual, though, it's hard to make
any hard predictions.

> The second has to do with scene graphs. There appears to be an implicit
> assumption in Fresco that the server will hold an arbitrarily large
> amount of state on behalf of a given client connection. The key question
> is: who pays for this storage? If the answer is "the server" then we can
> stop -- Fresco isn't going to work for us.
>
> Managing multiparty storage is going to turn out to be one of the basic
> design pattern challenges in EROS. The problem is that (a) we need to,
> and (b) it is *very* hard to write code that survives when the memory it
> references is able to become spontaneously invalid (as when a client
> shoots its space bank). I will be interested to see how we end up
> managing this in our window manager.

I'm not terribly familiar with EROS, so be gentle :-).  But as I
understand things, a "space bank" is a chunk of memory that program A
loans to program B via the transfer of a capability, and this loan can
be called in at any time.  The issue here is whether Fresco can 1) make
sure to use only memory borrowed from clients when allocating objects
on the behalf of clients, and 2) deal reasonably if that memory
suddenly disappears.

As it turns out, we already have all the architecture we need to solve
both (1) and (2), for entirely different (though perhaps related)
reasons.  (1) is easy -- in the case of client crash, we have to be
able to jettison all of the client's state, which means that
allocations already have to know which client they're being performed
on the behalf of.  Modifying this to use a special per-client
allocator wouldn't be a terribly big change.  You'd have to do a bit
of work to make sure that anything those objects allocated on the heap
also went into the right space bank, but I think that'd be doable,
though possibly it'd require some tweaking of STL and some extra
memory overhead (since every object would need to keep track of which
space bank it should allocate out of).

(2) I'm less sure about, because I don't know exactly what happens
when a client shoots its space bank -- does the next attempt to
traverse a pointer into that memory throw a nice exception (assuming
C++ here, because that's what Fresco is written in), or what?  If it
does, then again, solving this is trivial -- because we currently
allow for scene graph objects to be remote, we already have to deal
with the possibility that any given node will disappear; dealing with
the scene graph case would just mean adding a new exception to our
catch clauses.  There might be some care required in case the object
whose code is currently running disappears from under our feet, but it
should be manageable -- just be aware of the possibility, and make
sure that if it happens you throw an exception and get out.

So I think Fresco can pass your first round of requirements, at least
provisionally.  There are, of course, a whole lot of other issues to
deal with, ranging from client<->server communication (Fresco uses
CORBA -- I've been interested in EROS and E for their pleasant
security guarantees, which CORBA entirely lacks -- but would
Fresco-on-EROS be restricted to only local clients, for example?  And
if you do want to support remote clients, who pays for the memory?)
Also, over in Fresco-land we've hardly thought about security at all
so far.  I see you've already mentioned some of the nasty cases
(screen scrapers, fake events, etc.); another really fun case that
comes to mind is application embedding (cf OLE/Bonobo/KParts/OpenDoc),
where multiple applications are actually coordinating to produce a
single GUI.

(In fact, application embedding raises another issue with space banks
that perhaps someone can explain to me.  Imagine a scene graph that
looks like
  A -> B -> C
where A belongs to the server (it's the root desktop node, or
whatever), B belongs to one application, and C belongs to another
application that's embedded in B.  If the app that owns B now shoots
its space bank, B will disappear, orphaning C.  The way we do things
now, the server will correctly notice that B doesn't exist, and sever
the branch of the scene graph that was formerly rooted at B; however,
we've now lost track of C entirely.  If a shot space bank guarantees
that destructors for objects stored in it will be called, then this is
no problem -- B's destructor will decrement C's reference count, and C
will suicide if appropriate.  I'd guess, though, that you don't call
destructors, because of the lack of guarantee of timely termination,
so probably that doesn't work.  Alternatively, the could server track
the graph topology in reliable server memory, but that lets clients
steal arbitrary amounts of memory again, by creating arbitrarily
complex GUIs.  It seems, then, that a garbage collector is required,
if you want to do scene-graph-based graphics on EROS?  It feels like
the problem could be more general, though, so I'm curious if anyone on
this list has any comments.)

-- Nathaniel

-- 
Damn the Solar System.  Bad light; planets too distant; pestered with
comets; feeble contrivance; could make a better one myself.
  -- Lord Jeffrey

This email may be read aloud.