#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 -----------------------------+---------------------------- Changes (by bonefish): * component: Servers/app_server => System/Kernel Comment: Replying to [comment:20 axeld]: > Is priority inversion really so hard to circumvent, though? If we only put this functionality into mutex, it would just need to adjust the current lock holder's thread priority if a higher priority thread enters its wait queue, right? That's the basic idea. There are a few details that complicate things, though. When a thread unlocks a mutex (or transfers ownership) its priority possibly needs to be adjusted again. Since it can also hold other mutexes at that time, the thread needs to maintain a list of mutexes it holds, so the correct new priority can be determined. That also requires us to check whether all code that uses mutexes explicitly destroys them. Timeouts on mutexes add to the fun (as the holder's priority might need to be adjusted). That's all doable, but not completely trivial either. -- Ticket URL: <http://dev.haiku-os.org/ticket/8007#comment:23> Haiku <http://dev.haiku-os.org> Haiku - the operating system.