Re: Patch to Pistachio's comportement on Xfer timeouts

[Marcus Brinkmann]

At Fri, 21 Jan 2005 16:19:53 +0100,
Espen Skoglund <address@hidden> wrote:
> Er... so what you're saying here is that a thread doing an IPC (send
> or receive) can not decide on the timeouts for page-faults within its
> own address space.  If a page-fault occurs within its own space, the
> thread *must* rely on its pager to provide a valid mapping within a
> given time period (since it can not trust the IPC partner to have set
> a proper timeout value).  Do you seriously consider this to be a good
> idea?

The pager can also generate an exception and cancel the pending IPC,
which is what will happen if a valid mapping can not be generated.

> What Marcus says might be right for his particular usage case.  In
> general, however, the server may very well have a great interest in
> IPC pagefaults within its own space.

This is why I suggested two options to Matthieu: The one Matthieu
actually implemented, and a different one, which I also proposed on
the l4ka mailing list some time ago without receiving much response:

The alternative is to have four xfer timeouts: local pf send phase,
local pf recv phase, remote pf send phase, remote pf recv phase.  This
requires a second xfer timeout word for every IPC.

The L4.X2 specs treat local and remote pagefaults during string item
transfers identical.  I think in general, threads do have a great
interest in making a distinction and handle local pagefaults and
remote pagefaults differently.  This is impossible with the current L4
design: It does not allow for this flexibility.

Are you interested in a patch that adds another xfer timeout word and
allows to make such a distinction?

BTW, retrying the IPC is not an option, because the server can not
wait until the client is rescheduled and has investigated the result
and actually re-entered the receive phase.  So, the server could try
to continue the reply, but it would be a matter of luck.  If the
client is not ready, the message would have to be dropped, and the
whole RPC would have to be retried---if that is possible at all for
the type of operation in question.

Thanks,
Marcus