On Wed, 2005-10-12 at 13:52 +0200, Matthieu Lemerre wrote: > "Jonathan S. Shapiro" <[EMAIL PROTECTED]> writes: > > > On Tue, 2005-10-11 at 01:15 +0200, Matthieu Lemerre wrote: > >> "Jonathan S. Shapiro" <[EMAIL PROTECTED]> writes: > > > >> > But I think that the real difference lies in the fact that our system > >> > tends to favor designs where storage used by a server is allocated from > >> > a homogeneous source. This greatly simplifies matters. > >> > >> What do you mean by homogeneous source? > > > > I mean that in most of our objects, all of the storage comes from a > > single storage allocator. As long as there is only one source of > > storage, there is no complexity managing it. The complexity only begins > > when you must manage storage from more than one source. > > And different clients have different storage allocators, so the > problem arise when one server has to provide objects allocated by > several clients.
Yes. And it is sometimes a pain, but those cases are fortunately rare. But here is another way to look at it: In most systems, there is no accountability for storage at all. This means that you don't have to worry about mixing up sources of storage, but it also means that you have absolutely no ability to control storage abuse and storage denial of service. In any system where storage allocation is accountable, there must be some abstraction in the system that captures the notion of a "right to allocate storage" (this is also a natural place to do the counting). The benefit of accountability is that you gain control. The cost of accountability is that you now need to deal with the issue. This appears to be one of those places where a foundational policy decision must be made. The policy decision is: "Will we make storage accountable?" The answer determines whether it is possible to prevent resource denial or not. Hmm. That is not quite precise. I can do storage accountability without imposing limits, and this does not resolve the problem of storage denial; it simply provides a measurement tool. In practice, the real problem with storage accountability is that I must now worry about what happens when somebody wishes to reclaim storage, and in order for that to work in a vaguely sensible way I must ensure that a single object does not destroy its underlying storage from multiple sources that might be independently revoked. If you will pardon an abused metaphor: half an object is not always better than none. However, here is an analogous problem. Consider a real-time system where we have dynamic libraries. Imagine that each real time process has a quota for page frame pinning. Obviously, we would like to avoid redundantly pinning the shared C library, but managing this is exactly an example of mingled backing resource. In the specific example of the C library, the right answer is probably that it should simply be pinned globally by the system, but for other libraries that answer becomes progressively less appropriate as the library is less universally used. Of course, I could also simply let everyone use the same space bank. This "solves" the mingled resource problem at the cost of eliminating all control over storage. Any of these resolutions is possible using the EROS mechanism. > > The time server is not a good example. In the case of the time server, > > the right thing is for the server to allocate a *single* page from > > *server* storage, put all three times in it, and simply hand out > > read-only capabilities to that page. All clients access the same page. > > I was going to object and ask : when is the storage freed then? And I > realized that this time server would have been set up by one client, > and its storage would have been the client's storage. I imagine that > the client has then special control over the server to create the time > objects. > > Now I think that I see how this works. Umm. I think you see how it works, but the time server is still a bad example. As a practical matter, the time server probably wants to be a system-wide resource that uses a fixed amount of global storage. So in practice, its storage will come out of the pool granted to the installer by the system installation process. > Thanks. I have now a much clearer idea of how it works, and I now > believe that we can indeed get rid of reference counting. If that proves to be correct, it would be wonderful. Let us see what other places reference counting is currently used that may still surprise us. shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
