Scribit Jonathan S. Shapiro dies 27/04/2006 hora 06:36: > If the payloads do not match, the destination process will never know > that the capability was invoked.
But what if the PP match? We need a way for a watchdog to chech that reply can be made. > 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. It is cheaper but I still ain't convinced it achieves the same features. And severing the FCRB would only occur when operation is cancelled. In fact, it would only occur when operation is cancelled and should be forwarded... Maybe an optimization to the protocol would be to advertise it is handled. Then any process who's next server in the chain did not advertise cancellation forwarding would not sever the FCRB and only increment PP. > > 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. I understand that, really. The problem is, what happens when payload match, when invocation purpose was to test the validity of the FCRB? > 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 Could you elaborate? Does incrementing the PP will invalidate the previous sender's capability? If not, what would be the result of classify() before and after PP increment? I.e., would they be different? Curiously, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A
signature.asc
Description: Digital signature
_______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
