Scribit Jonathan S. Shapiro dies 26/04/2006 hora 20:14: > In general, the only subsystem that has permission to sever is the > storage allocator. C can *request* that the object be severed by > returning it to the allocator. This is a multiple-IPC sequence.
OK, it's heavy, but it will only occur at cancellation. I said it would also upon completion, but that defeat the very purpose of having a protected payload match. So, my cancellation forwarding protocol adds a big overhead, but only upon cancellation. > It is better and faster to just update the payload if what you are > trying to accomplish is to block the second and subsequent replies. 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. > But this requires periodic polling, a.k.a. a watchdog. In which case, > why not use the watchdog in the first place! I do use a watchdog. The fact is, I want the watchdog to add the smallest overhead possible. And my watchdog does not set a timeout (for now, watchdogs and timeout have been said equivalent, obviously they're not). Now here are the two scenarios in my protocol: Successful operation: ===================== - C invokes a cap to S, giving S a cap c1 to a FCRB->C - S sets up a watchdog that will check that c1.getType() != 0 - S invokes a cap to T, giving T a cap c2 to a FCRB->S - T sets up a watchdog that will check that c2.getType() != 0 ( T successfully treat the request, now goes completion ) - T invokes c2 - S reads the answer, and increment the protected payload of the FCRB->S, thus blocking subsequent replies - S invokes c1 - C reads the answer, and increment the protected payload of the FCRB->C, thus blocking subsequent replies Uncomplete operation: ===================== - C invokes a cap to S, giving S a cap c1 to a FCRB->C - S sets up a watchdog that will check that c1.getType() != 0 - S invokes a cap to T, giving T a cap c2 to a FCRB->S - T sets up a watchdog that will check that c2.getType() != 0 ( for any reason, C decides to stop, now goes cancellation ) - C severs the FCRB->C, c1 becomes a null cap - S watchdog notifies S of cancellation - S severs the FCRB->S, c2 becomes a null cap - T watchdog notifies T of cancellation Now the benefits of this protocol are: - I'm not sure it is possible to make the watchdog's checks more lightweight, both in terms of the number and simplicity of operation (one getType() on a cap, compared to a constant) and of memory pressure (neither the client nor only it's FCRB need to be paged in) - the watchdog apart, there is no modification to the existing communication protocol nor in the use of the FCRB (you use the ligthweight feature of modifying the protected paylaod to block subsequent replies) - only cancellation needs a heayweight operation, severing the FCRB, which is a multiple IPC mechanisms with the allocator Note also that when N clients in the chain support cancellation forwarding, and M not, you will have at most N of these heavyweight operations (any of the N clients being successors of any of the M ones won't get the 'cancellation signal'). Lighweightly, 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
