#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: 7882, 8136 Has a Patch: 1 | Platform: All -----------------------------+---------------------------- Comment (by jua): Some status update... * I created another branch in which I'm experimenting with the RW-lock guarding. At first it was not better than an unmodified Haiku, it still had the heavy freezing. I suspected classic writer-starvation and wanted to see where those writers came from. When I added some tracing-dprintf's I learned another thing... * ... In my previous comment I wrote that I left the team-port-list locked by a regular mutex even in the lockfree-hash branch -- I had assumed that accessing it would be rare... oh how wrong I was! * Was surprised to find that just moving the mouse cursor causes torrents of calls to `set_port_owner()`, constantly changing the ownership of a port back and forth between registrar and whatever application is responsible for the area below the mouse pointer. I so far know only little about app_server/registrar internals, so I just assume that this ownership-pingpong is intentional and not a bug? Anyway, `set_port_owner()` is not as lightweight as the function name makes it seem, it has to lookup a team ID, lookup a port and then atomically move the port from one list to another... and all that protected by a single mutex (and in the RW-lock-branch version it always acquired the lock for writing) * So another way to handle the team-port-list was needed. Two solutions came to mind: a) a separate lock per team as part of the team data structure or b) lock striping. I've gone with b) for now and it works well enough. Instead of a single mutex guarding all team-port-lists there is now an array of 8 mutexes. When code wants to access the list of team `x` it has to lock mutex number `(x % 8)`. The choice of '8' is somewhat arbitrary, maybe 16 would be better, or maybe not... guess I need to benchmark there. * With the lock-striping on the team-port-lists, the situation is ''much'' better for the RW-lock-version. It now has as little freezing as the lockfree-hash version -- i.e. the freezing is not totally gone, but much better. I've then also integrated the striping into the lock-free branch, there it doesn't seem to make much difference though in regards to freezing. * I've also implemented the ports-by-name hash and using that in the RW- lock version for `find_port()` lookups. Doesn't influence the freezing though because `find_port()` is rarely called (at least in my current test cases). The remaining suggestion about the locking order is still to be tried out. * I'm curious why there is still a little freezing in both branches. These remaining issues are most probably unrelated to the ports list, maybe contention on another kernel structure or something else. This is the next thing I want to find out about. -- Ticket URL: <http://dev.haiku-os.org/ticket/8007#comment:87> Haiku <http://dev.haiku-os.org> Haiku - the operating system.