IPC Timeouts

[Jonathan S. Shapiro]

On Thu, 2005-02-24 at 02:08 +0100, Marcus Brinkmann wrote: 
> > Marcus's approach of using a zero pager
> > timeout in server->client sends implies that the client must have means
> > to pin its receive area (a client-defined number of page frames) for an
> > indefinite time (there may be no contract on how fast the server
> > replies). This can induce a very real and urgent resource denial of
> > service problem...
> 
> The reason why I hope we will get away with it is that we are pursueing
> a model where every task is self-paged.  Tasks get a contingent of
> physical memory, which is guaranteed over a long time (exact details
> how to negotiate that number are not determined yet)...

This would certainly look initially attractive, but let's dig in on it a
little bit.

First, let us make the assumption that all string items returned from
servers have a length that is known at client compile time -- the
dynamically sized return strings need to be handled through other
mechanisms anyway.

So: given a client's source, we can determine the longest reply string
it will receive.

This number effectively sets a least bound on the number of pages of
that client that must be pinned in order for the client to receive these
IPC replies. Note that "pin" is a commitment to *real* memory, not
virtual memory.

I believe we will shortly conclude that the design effectively sets a
hard limit on the number of client processes that can be effectively
run.

> The physical memory server needs to be able
> to revoke arbitrary mappings temporarily, for example to make space
> for DMA buffer regions or to reorganize memory for super-page
> allocation.  This means that the operation of the physical memory
> server is not transparent to the clients, and thus even to the server.
> (Only the kernel could make this operation transparent by an atomic
> copy-and-remap operation).
> 
> So, yes, the whole notion is troublesome.

I don't like having a universally trusted paging agent either, but in 15
years of thinking about this in my spare cycles I haven't come up with
anything better yet. :-)

> > In all current
> > L4-derived systems, the region manager (or the software that plays the
> > equivalent functional role) is necessarily trusted completely by all of
> > the programs that it serves.
> 
> Well, we are at least trying.  If it is feasible we will see when we
> have implemented it...

Good luck. If my comments help to resolve what the critical collision of
design objectives may be, and perhaps what degrees of design freedom
might exist to resolve it, then they have perhaps achieved something
useful.

> > It appears to me that this amounts to a special case of a more general
> > problem: non-blocking reliable delivery of event notification. We have
> > run into places in EROS where there is a serious need for such a
> > mechanism, and we have been contemplating how to achieve this in
> > Coyotos. We have now concluded that it should *not* be done in
> > endpoints, because it is extremely desirable for endpoints to be
> > stateless and pending events must be recorded somewhere. It is unclear
> > at this point what alternative will emerge.
> 
> Yes.  For me, such issues tend to crop up when I think about
> cancellation (for example due to signals).  Due to lack of low-level
> support, we will have to do it with expensive and complicated high
> level constructs in the endpoints.

Since this is a separate topic, I shall reply separately with a new
subject line.

shap