On Tue, 2006-04-25 at 00:46 +0200, Bas Wijnen wrote: > So forget about all others for the moment, please.
I am not interested in considering move-only capabilities. We looked at them several times over many years and decided that (a) they create more problems than they solve, (b) they don't actually solve any of the problems that people *think* they solve, and (c) they have negative performance consequences. Coyotos will not implement "move only" capabilities. Period. > > > The case when many capabilities are overwriten with a single IPC is > > > most likely a bug in the server. > > > > Actually, it is the near-universal practice for a single-threaded > > server. Arguments are commonly accepted in a way that overwrites the > > arguments from the last invocation. > > This is not a problem. The invocation only happens when valid send-once > capabilities get overwritten. Each and every valid send-once capability is > directly related to a client waiting for a response. If you overwrite it, it > will never get that response, because you are guaranteed to be the only party > who is capable of responding. Yes, so now you have a situation where client A is notified of the server's mishandling of client B. This is a security error. Coyotos will not expose this fact. > > Or to put it another way > > > > move =def= copy + drop > > drop => drop notice > > drop notice => invoked capability > > invoked capability => invalid capability > > invalid capability => no valid response ever > > As Marcus also pointed out already, this does not define the send-once > capabilities we were talking about. You are confusing "send once" with "move only". Please pick one. shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
