[haiku-appserver] Re: Overlay support
- From: "Rudolf" <drivers.be-hold@xxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Tue, 25 Apr 2006 12:44:11 +0200 CEST
Hi :)
> jonathanthompson@xxxxxxxxxxxxxxxxxxxxxxx wrote:
> > Perhaps we aren't visualizing the same reality here: do you mean
> > you
> > consider it perfectly acceptable to kill an application that
> > doesn't
> > jump
> > when you say "Jump right NOW!" when it is very busy, because the
>
> Exactly, that's the idea behind it. If it is designed in a way that
> it
> cannot answer in a timely manner, I consider this a bug in the
> implementation of this application. And we definitely don't need to
> live with those, IMO.
I agree. A line has to be drawn _somewhere_. :)
(also a stable system outweighs a kept running (un)stable app. the
system should only probably issue these kind of things if it's own
integrity comes into trouble otherwise)
> > system is so loaded down that it is swapping heavily, for instance?
> > The application could be working perfectly correctly, and doing
> > things as
> > timely as reality could ever permit given the resources, but it
> > simply can't
> > respond *that* quickly, due to hardware limitations it can't
> > control.
>
> I don't think there are any excuses for being that late. Swapping of
> course could be detected and timeouts postponed if this turns out to
> be
> a problem. But honestly, I don't think it will; if a team is playing
> video it doesn't make any sense to swap it out, and our VM will be
> very
> hesitant towards swapping out applications anyway. But we'll see how
> that turns out :)
My take is that the timeouts should be as high as possible to have the
best.
-slow enough so even the slowest (reasonable) app can respond
-fast enough the systems remains stable, and the user isn't tempted to
do that 3-finger salute or even press 'reset'.
'reasonably' can be defined and finetuned over time. For starters I'd
take Be's values, they have a background, no doubt.
Bye!
Rudolf.
Other related posts:
