diff options
| author | GNU Hurd wiki engine <web-hurd@gnu.org> | 2008-03-20 19:25:31 +0000 |
|---|---|---|
| committer | GNU Hurd wiki engine <web-hurd@gnu.org> | 2008-03-20 19:25:31 +0000 |
| commit | a557877f5ff3e944d969363c7ab5285bd798c7cf (patch) | |
| tree | 944afca6286df6930ec9a0ab6115e00ddd6a559e | |
| parent | 8561976cfff5e55347f52964cf1f33650eb9add0 (diff) | |
web commit by DavidSarahHopwood: minor
| -rw-r--r-- | hurd/ng/cancellationforwarding.mdwn | 16 |
1 files changed, 8 insertions, 8 deletions
diff --git a/hurd/ng/cancellationforwarding.mdwn b/hurd/ng/cancellationforwarding.mdwn index 1b7776f2..1dadb490 100644 --- a/hurd/ng/cancellationforwarding.mdwn +++ b/hurd/ng/cancellationforwarding.mdwn @@ -2,9 +2,9 @@ ## <a name="Rationale"> Rationale </a> -When a request to one or more servers is needed from a server to process a request from it's client, and the client cancels it's request, there will be at least temporary resource leakage in the chain of servers. +When a request to one or more servers is needed from a server to process a request from its client, and the client cancels its request, there will be at least temporary resource leakage in the chain of servers. -If the last server in the chain completes processing and gives a response to it's client, there will be unnecessary CPU and memory usage from all the servers. And if one of the servers never completes, there will be permanent memory leakage. +If the last server in the chain completes processing and gives a response to its client, there will be unnecessary CPU and memory usage from all the servers. And if one of the servers never completes, there will be permanent memory leakage. Timeouts are a way to avoid the permament memory leakage, at the cost of rendering the whole communication impossible above some system load. They also only bring the duration of the memory leakage from infinite to some time. @@ -12,8 +12,8 @@ Cancellation forwarding is a mechanism that can be used to propagate, without ad ## <a name="Protocol"> Protocol </a> -* Each client that want to forward cancellation to it's server increment the protected payload of the FCRB for which a sender's capability has been given to the server, thus invalidating the capability. -* Each server that wants to notice cancellation forwarding will set up a watchdog, and ask the kernel to send heartbeats. At each heartbeat, the watchdog check that the reply capability to the FCRB of the client is not invalid, with a Discrim capability. +* Each client that want to forward cancellation to its server increment the protected payload of the FCRB for which a sender's capability has been given to the server, thus invalidating the capability. +* Each server that wants to notice cancellation forwarding will set up a watchdog, and ask the kernel to send heartbeats. At each heartbeat, the watchdog checks that the reply capability to the FCRB of the client is not invalid, with a Discrim capability. ## <a name="Example"> Example </a> @@ -33,16 +33,16 @@ Notation: ( T successfully treat the request, now goes completion ) * T invokes c2 -* S reads the answer, and increment the PP of the FCRB->S +* S reads the answer, and increments the PP of the FCRB->S * S invokes c1 -* C reads the answer, and increment the PP of the FCRB->C +* C reads the answer, and increments the PP of the FCRB->C ### <a name="Uncomplete_operation_"> Uncomplete operation: </a> * C invokes a cap to S, giving S a cap c1 to a FCRB->C -* S sets up a watchdog that check that discrim.classify(c1) != clVoid +* S sets up a watchdog that checks that discrim.classify(c1) != clVoid * S invokes a cap to T, giving T a cap c2 to a FCRB->S -* T sets up a watchdog that check that discrim.classify(c2) != clVoid +* T sets up a watchdog that checks that discrim.classify(c2) != clVoid ( for any reason, C decides to stop, now goes cancellation ) |