[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