[coyotos-dev] Sleep, wakeup, and persistence
Jonathan S. Shapiro
shap at eros-os.com
Sun Sep 30 14:28:35 EDT 2007
On Sun, 2007-09-30 at 19:59 +0200, Valerio Bellizzomi wrote:
> On 30/09/2007, at 11.32, Jonathan S. Shapiro wrote:
>
> >On Sat, 2007-09-29 at 12:40 +0200, Valerio Bellizzomi wrote:
> >
> >> I think that the application's ability to react to restarts should be
> >> defined in the scheduling contract.
> >
> >Exposing this via the scheduling contract exposes it to everyone, which
> >is something we definitely do not want to do. I think it is better to
> >try to keep this separate from the scheduling mechanism.
>
> I was believing that the scheduling contract was per process, and that the
> schedule capability is not exposed to everyone. Can you expand on the
> design and implementation of the scheduling contract ?
We have a term collision.
The schedule capability is part of your process state. It describes the
schedule you are executing under, and it is exposed to anyone holding
the process capability of that process. Multiple processes may have the
same schedule capability, in which case they operate round-robin within
that schedule.
Real-time schedules will be built by an admission control agent. It is
not clear how widely access to that agent will be available.
In any case, the point where you negotiate your scheduling contract
really is not the right point to negotiate your checkpoint awareness
objectives. The two things can be cleanly separated.
shap
--
Jonathan S. Shapiro
Managing Director
The EROS Group, LLC
www.coyotos.org, www.eros-os.org
More information about the coyotos-dev
mailing list