At Thu, 3 Nov 2005 11:47:02 -0700, "Christopher Nelson" <[EMAIL PROTECTED]> wrote: > > > At Thu, 3 Nov 2005 11:21:17 -0700, > > "Christopher Nelson" <[EMAIL PROTECTED]> wrote: > > > Sure, but in practice how does this work? > > > > In practice it works by first defining what your system looks > > like, and then finding out what the constraints are. > > > > The problems you describe stem from the fact that you have a > > service that is used by multiple users concurrently, and > > which expends some of its own resources in handling those messages. > > Actually, I didn't mean that at all. Say thread A allocates 4gb of > memory. Say it then shares that memory with thread B.
What's the relationship between thread A and B? There must be a reason for A to share the memory with B. B must _allow_ the memory to be shared with A. Why is the memory mapped, and not copied? Unless you define the relationship between A and B, you can not derive anything about possible operations. > Thread B cannot > do any meaningful work on that memory until it is mapped into it's > address space. Thread B *must* use some of it's own resources (if you > consider space in your address space a resource) in order to do any > useful work on that information. This is true, but it becomes a moot point if B and A use exactly the same resources, for example because B was instantiated by A. Without knowing more about A and B, we can't tell if that is a problem or not. > Lol. I'm not sure exactly what you're saying, but I *think* that I agree > with you. :-D I don't so much mean that the kernel should impose it's > own idea about how much it's going to transfer, but rather that it > provide a mechanism which allows the receiver to say how much it wants > to receive. The receiver should not be *forced* to accept what it is > given. I agree with the last sentence. But what you say before is not true in general. The kernel must impose its own limit on a message size as well. If you need/want to exceed that limit, then you have to implement higher-level protocols, which of course add their own problems. Thanks, Marcus _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
