IPC Timeouts

[Espen Skoglund]

[Kevin Elphinstone]
> Summary: I'd argue strongly for absolute time events specified
> absolutely, not relative to some current time. There is obvious
> motivation for absolute wall clock events, but there may be cases
> for "absolute" events on a process virtual time scale. There maybe
> cases for relative time events on a process virtual time scale, but
> I think relative events based on wall clock (what we have now) is
> unusable where . The combination with IPC seems unwarranted.

I must say that I'm inclined to agree with much of this.  I have
*very* loosely been playing with the idea of having time/scheduling
domains that can somehow be managed using some form of map/unmap
mechanism.  A time domain could encapsulate a single thread, a
program, a collection of cooperating applications, a whole subsytem, a
virtual machine, etc.

Time events would be relative to a particular time domain.  Wall clock
time events would have to be specified within the root domain.

A reason why timeouts are currently specified within the IPC is that
doing so enables a program to invoke an IPC and set a timeout in one
atomic operation.  There is no risk of being preempted in between
setting the timeout and invoking the IPC.  Using time domains this
becomes a non-issue.  Time events (timeouts) are specified within a
particular time domain, and if the thread is preempted before invoking
the IPC it will not cause time to pass within this domain (unless of
course the next thread being scheduled consumes time from the same
domain).

Time domains may also give the possibility of performing time slice
donation in a more controlled manner.  They *may* also raise the bar
for creating time based covert channels.

What the exact semantics of time domains would be and whether such
time domains can be implemented in an efficient manner is of course a
completely different matter.

Anyhow, agreed, the manner in which we currently deal with many things
related to time and scheduling in L4 is somewhat... er... lacking.

	eSk