Re: On PATH_MAX

[Jonathan S. Shapiro]

On Wed, 2005-11-09 at 22:44 +0100, ness wrote:
> Jonathan S. Shapiro wrote:
> > On Wed, 2005-11-09 at 13:38 +0100, ness wrote:
> > 
> > 
> >>Why shouldn't the thread of execution and scheduling time be provided by 
> >>the caller, too?
> > 
> > 
> > Short answer: because then the provider could terminate the schedule
> > while the thread was executing within a critical region within the
> > server.
> > 
> > Game Over.
> > 
> Hm. This is a serious problem. But sth. makes me feel it would be nice 
> to make the caller pay. But you're right, we want the caller to be 
> allowed to remove the thread or no longer pay for the scheduling.
> Just out of curiousity:
> Do you think it is possible to fully make the caller pay? I see two 
> ways: the one way is to design every server without such critical 
> regions (what's impossible, IMHO), or the server would need some more 
> promises... Maybye it was possible to grant the thread of execution and 
> make sure the caller cannot stop paying within such a critical region...
> *consfusing*

Yes. Definitely icky.

I've spent some time thinking about this. I haven't got any answer that
I am happy with, but here is the best I've got so far.

The best we can do is have the client supply the scheduling authority.
If this is done, then both sides need to agree -- client needs to offer
it explicitly (via a donate bit) and service needs to *accept* it
explicitly. Otherwise, a low-priority client could cause a time-critical
server to end up running off of a low-priority scheduling class.

If the client can supply a schedule, the server MUST have a fallback
schedule. This is needed because the server MUST be able to exit all
critical regions, including the final IPC return, even if the client
defects. The fallback schedule isn't that hard to get. All we need is a
mechanism for the server to say "I want to receive a fault if my
schedule becomes invalid". The fault handler can then supply a fallback
schedule.

The real problem is that the server has no way to know whether the
caller is higher priority, so there is no way for it to make a decision
about whether to accept the incoming schedule without inspecting it
first. Worse, *real* scheduling systems use dynamic priorities. When a
real-time scheduler is in effect, I can hand you a schedule that has the
highest dynamic priority of anything in the system right now, but in 2ms
the priority of that slice is going to go to zero and stay that way for
hours. This means that there is no real way to inspect, because the
answer is going to change.

Finally, priority inheritance doesn't always help in a general-purpose
IPC system, because the priority escalation strategy cannot always find
the correct thread to escalate.

My suspicion is that there will turn out to be a simple way to resolve
all of this that will work well enough in practice. This is one of the
things that I am hoping to sort out with Neal's help soon. It's a
discussion that needs a whiteboard and a beer -- or maybe too.

shap