l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: EROS/Coyotos address spaces


From: Jonathan S. Shapiro
Subject: Re: EROS/Coyotos address spaces
Date: Thu, 27 Oct 2005 19:13:45 -0400

On Thu, 2005-10-27 at 21:10 +0200, Bas Wijnen wrote:
> 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?

So first, the case you are concerned about here is non-orderly shutdown:
the situation where the client had no opportunity to say "I am done".

And second, this is also a case where the server is non-exclusive (and
therefore is not destroyed along with the client).

The pattern you identify is *very* rare, and I don't think that we have
a general answer for it. Let me describe how we deal with this in the
window system. A similar solution is used for the current ethernet
driver.

The per-client state in the window system divides (conceptually) into
two parts:

  1. A shared-memory region whose storage is supplied by the client.
  2. A window system data structure that records the depth and position
     of the client window.

The data structure is allocated from the window system heap using window
system storage.

If a client evaporates, the shared memory region evaporates with it. At
some point after that, the window system will go to execute bitblt()
from the window region, and take a (recoverable) page fault [1]. At this
point it will discover that the session has disappeared and it will
reclaim the data structure.

[1] The recoverable page fault check in bitblt() is necessary anyway,
because a hostile client might revoke the shared memory region in an
attempt to break the window system.


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

I do not understand the case you are describing. If the object is stored
in client storage, it is gone, because the storage has been reclaimed
when the client was reclaimed.

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

In the window system that is actually how we do it. It is not as brittle
as we initially feared, but this is probably true for reasons that are
specific to the window system.

I'm still not confident that I am getting at your question properly.


shap





reply via email to

[Prev in Thread] Current Thread [Next in Thread]