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.