Re: Reliability of RPC services

[Pierre THIERRY]

Scribit Jonathan S. Shapiro dies 22/04/2006 hora 13:53:
> > > couldn't S drop it's capability in a way that won't trigger the
> > > send that the "invoke on delete" bit asks for?
> > IIUC, that would enable a malicious S to let C be waiting
> > indefinitely for the answer
> It is not possible in principle to prevent this. Do the exercise:
> design an S that achieves this denial even if "send on overwrite" is
> present.

OK: S keeps the capability and just don't bother giving answer to the
request... I was too focused on the case where we want to kill S when we
find it is malicious (or buggy, FWIW).

So what should C do to avoid memory leaks (he asks for something through
a capability, providing the space for the answer, and never gets
anything, probably several times) or freeze (when waiting for an answer
to continue it's work).

In some cases, I suppose human intervention is possible, like when a
process waits for a device driver to perform (typically disk write) that
cannot, but that's not suitable everywhere. There are many cases where
we could expect the system to recover nicely by it's own. Are timeouts
to be avoided most or all of the time? What are the alternatives?

Curiously,
Nowhere man
-- 
address@hidden
OpenPGP 0xD9D50D8A

signature.asc
Description: Digital signature