FreeLists / haiku-appserver / [haiku-appserver] Re: Overlay support

["Rudolf" <drivers.be-hold@xxxxxxxxxxxx>]

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.