[haiku-bugs] Re: [Haiku] #8007: [app_server] fully unresponsive when resizing window of big textfile

  • From: "bonefish" <trac@xxxxxxxxxxxx>
  • Date: Tue, 08 Nov 2011 17:05:09 -0000

#8007: [app_server] fully unresponsive when resizing window of big textfile
   Reporter:  ttcoder        |      Owner:  axeld
       Type:  bug            |     Status:  new
   Priority:  normal         |  Milestone:  R1
  Component:  System/Kernel  |    Version:  R1/Development
 Resolution:                 |   Keywords:
 Blocked By:                 |   Blocking:
Has a Patch:  0              |   Platform:  All

Comment (by bonefish):

 Replying to [comment:24 axeld]:
 > I would implement an easier approach at first, and see if that already
 serves us good enough, namely just boosting the next quantum of that
 thread. But you've probably removed the thread::next_priority field
 already in the mean time, I guess? That would make this change really

 `Thread::next_priority` is still there. Since it is only used (and
 immediately reset) in `enqueue_in_run_queue()` that implementation might
 not be that simple either.

 > Implementing the real thing unfortunately also makes mutexes a bit more

 Memory-wise it should be three pointers (list link and thread pointer)
 plus maybe a priority field and minus the counter field. Performance-wise
 it shouldn't affect uncontended locks at all. It should still be possible
 to implement `mutex_{lock,unlock}()` for a mutex that isn't locked
 respectively on which no other thread is waiting inline as an atomic
 operation. Only the less likely operations will become more complex.

 I have to amend what I wrote in my previous comment: There's no need to
 maintain a list of all locks a thread holds. It is sufficient to include
 only the locks that other threads are waiting on. That also relieves us
 from reviewing all code that currently uses the locks we would change with
 respect to explicit lock destruction, since a lock a thread is still
 waiting on mustn't be destroyed anyway.

 Replying to [comment:25 SeanCollins]:
 > @bonefish
 > I do not have any changes made to the kernel debug levels. I can reduce
 those settings and retest to see if the build time is dramatically
 effected ?? Thank you for the explanation

 It's a compile time option. Have a look at the `build/config_headers`
 directory, particularly the `ReadMe` and `kernel_debug_config.h` (the
 `KDEBUG_LEVEL` definition). I probably wouldn't call the effect on the
 build time dramatic, but it's definitely significant. The effect on the
 kernel time alone is even more significant.

Ticket URL: <http://dev.haiku-os.org/ticket/8007#comment:26>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.

Other related posts: