[LITMUS^RT] Supporting Job Aborts

[Glenn Elliott]

On Sep 7, 2012, at 2:57 PM, Björn Brandenburg <bbb at mpi-sws.org> wrote:
> On 07.09.2012, at 19:29, Jonathan Herman <hermanjl at cs.unc.edu> wrote:
> 
>> For Glenn's current issue, setitimer may give the correct result. I
>> can imagine other situations where it wouldn't work. Suppose some kind
>> of slack stealing is in effect, and the current task overexecutes, but
>> this can be handled by the slack. We don't want the timer going off
>> and having the task quit in this case.
> 
> In that case, I'd add a flag to mark the timer (or task) as "postponable on slack donation". Then the expiry time of the timer could be pushed back automatically on slack donation (and even advanced when, say, stealing budget from low-criticality tasks). 

I see how a task could push back its budget if it received extra time through stealing.  I suppose this information would have to be passed through control pages.  However, this still requires the application to handle the timer twice, right?  Steps: initial setup, original expiry{, reinitialization, revised expiry}*.  This seems a little less efficient, but it is a cleaner approach.  I'm not sure how stealing works though.  How do we move the application-level budget timer forward in a remote process (the process we're stealing budget from)?  If there is a solution to do that, then we could use the same method to push timers back in others.

-Glenn