On Thu, 2006-04-27 at 11:37 +0200, Pierre THIERRY wrote: > Scribit Jonathan S. Shapiro dies 27/04/2006 hora 05:18: > > > But I'm not sure it is what I want. In fact, now I'm pretty sure > > > it's not. To just block subsequent replies is needed upon > > > completion, but for cancellation forwarding you need a bit more. > > Can you say why you believe this? I think there is a hidden assumption > > here that may be mistaken. > > My assumption, confirmed by what you say just below, is that the check > you're suggesting needs to invoke the capability to the FCRB, thus > needing to page it in, and the owner of the FCRB then to process the > incoming activation.
You misunderstand. The payload comparison check is performed entirely in the kernel. If the payloads do not match, the destination process will never know that the capability was invoked. This is also true if the process tests to determine whether the capability is invalid. Yes, the target FCRB object must be in memory, but consider the alternative: in your plan, you will sever the FCRB, but after you do this you immediately need to go buy a new one so that you can make your next call. Incrementing the payload has the same effect at much cheaper cost. Indeed, one way to think about the way the payload is used for reply capabilities is that it reduces the number of required sever operations by 2^32. In fact, the implementation of an FCRB that will accept at most one reply is accomplished exactly by changing the protected payload in this way. > But section 6.1 describes the invocation of a FCRB sender's capability, > and it seems to always lead to a delivery. Go back and read step 1 again. Look more carefully what happens when the payload does not match. > So how do you intend the watchdog to perform the test? And how the > client is supposed to discriminate between the test and the actual > answer? The capability does not need to be invoked to determine whether it is still valid. the Discrim.classify operation will tell you what you need: http://www.coyotos.org/docs/ukernel/spec.html#55 [I just noticed that link targets are getting generated incorrectly for the object reference section. This means, unfortunately, that the link above will go stale. It is a link to the "operations" subsection of the Discrim capability.] _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
