IPC Timeouts

[Marcus Brinkmann]

At Wed, 23 Feb 2005 17:24:47 -0500,
"Jonathan S. Shapiro" <shap at eros-os.org> wrote:
> Some might object that the pager should not have to be trusted. What is
> emerging from the discussion at hand is that this architectural view
> does not map well to real usage. 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, and may be in contradiction with the residency policy
> requirements under which the client must operate. It works very well in
> non-paging environments such as embedded applications.

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).  There are many
complications, but in the end this allows the client to make paging
decisions itself, and thus it can wire down a region of memory
effectively.

Sounds good, but there is a problem, and I think this just illustrates
the point you were making: 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.

> Just to be clear: I'm certainly not claiming for an instant that EROS
> got this stuff perfect. And I think it would definitely be nice to have
> a paging agent that could be outside of the universally trusted
> computing base. Unfortunately, nobody has been able to suggest a paging
> architecture in which this has turned out to be feasible. 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...

> > The timer event is
> > not dropped, but instead defered - the next time the thread does an
> > IPC, and there are no pending partners, it is canceled immediately and
> > does not block.
> 
> 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.  (Now, for us this is probably OK,
as we are going to need some such support anyway to correctly
implement POSIX semantics.  Still, it seems to be a burden and better
low-level support could possibly simplify things a lot).

Thank you also for your other comments, they are very much appreciated.

Marcus