Re: EROS/Coyotos address spaces

[Bas Wijnen]

On Sun, Oct 23, 2005 at 12:49:16PM -0400, Jonathan S. Shapiro wrote:
> > I understood previously that everything always pays for its own storage.
> > That sounds good.  However, I don't see how this can work.
> > 
> > There is a top level memory supply (called "prime space bank" if I
> > remember correctly).  I guess this space bank will give out parts of its
> > storage to anyone holding a capability allowing them.  How is this
> > recorded?  What happens when the client is destroyed?  That can happen
> > without notifying the prime space bank.  I'm sure the prime space bank has
> > some way to know that it can give out the memory to an other process, but
> > I don't see how.
> > 
> > Could you please explain this?
> 
> Well, I can try. :-)
...
> I don't know if this supplies a sufficient start at an answer, but before I
> put more time in to it let me wait for your response. I have skipped over a
> lot of detail about tricks for improving locality and amortizing storage
> better than this naive explanation would suggest, but is this enough to give
> you the idea?

I think it is.  Like in L4, a process is defined by an address space.  The
only way to exit a process is to destroy the address space.

But the question I had is not answered, probably because I didn't ask it
clearly enough.  I am trying again, but still have trouble with it.  Perhaps I
should first understand what I mean myself. :-)

I am assuming that in some cases, some client state will be stored in server
memory.  Be it a pointer to the actual object, or a capability, whatever.
When the client suddenly dies, this memory would stay in use, because the
server doesn't know about this death.  How is this cleaned up?

It is also possible that no client state is stored in server memory at all.
But then how can the server find the client object when it needs to do
something with it?  Will the client supply a pointer and is causing a page
fault something from which the server should recover?  That sounds very
fragile, so that's probably not it.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: Digital signature