Scribit Marcus Brinkmann dies 25/04/2006 hora 13:06: > Cancellation of the request in C is no problem. However, this > cancellation will have no influence on anything but C (at this point, > I am not considering cancellation forwarding).
But we were talking about sessionless protocols. I'm not sure we can achieve cancellation forwarding without sessions. Though there may be a mean: what if cancellation would just be some operation on the reply FCRB, and is it possible for a process to have some information about the FCRB it is planning to use to send the reply? I suppose this also needs the heartbeat. I'll temporarily name the operation severing the FCRB, though I'm not sure it is appropriate. This would become: - C invokes a cap on S, providing it a FCRB->C - S invokes a cap on T, providing it a FCRB->S - at each heartbeat, S checks the status of their reply FCRB - T doesn't reply in a timely manner - user cancels the operation - C severs FCRB->C - at the next heartbeat, when S checks the status of FCRB->C, it is informed it has been severed - S severs FCRB->S at this point, C and S have fully recovered from T's misbehaviour. There's no leakage. - if T also checks, relying on the heartbeat, the status of FCRB->S, it will also know operation has been cancelled, it too can fully recover IIUC, there's nothing to add to the current coyotos kernel interfaces to achieve this. To sever the FCRB, you just have to invoke the destroy method, AFAIK. Checking the status should just be a matter of checking getType() to know if the capability is a null capability. Allegedly, 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
