[haiku-appserver] Re: Overlay support

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.

> 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 point is that [...] the user should ultimately have control over 
> what dies and why

Of course, given different constraints, this would be favourable. But 
since this is easily solvable in the application (and a bug if it 
doesn't), and even only occurs in one of the two methods (you're free 
to choose which one you want to use), I don't see the need for this 
added complexity.

> leaves a lot to be desired, like (in too many cases) major details 
> such as the fact
> that a user space application can allocate lots of memory in the 
> kernel address
> range [...]

That won't be possible under Haiku.

Bye,
   Axel.

Other related posts: