#8007: [app_server] fully unresponsive when resizing window of big textfile ----------------------------------+---------------------------- Reporter: ttcoder | Owner: axeld Type: bug | Status: new Priority: normal | Milestone: R1 Component: Servers/app_server | Version: R1/Development Resolution: | Keywords: Blocked By: | Blocking: Has a Patch: 0 | Platform: All ----------------------------------+---------------------------- Changes (by bonefish): * cc: mmlr (added) Comment: Thanks, Pete! Looking at the analysis a few things are interesting: * The "cursor loop" thread, which I believe extracts the mouse events from the input server messages and updates the cursor position, shows no activity at all between 5.15 s and 6.95 s and only little activity afterwards (compared to its activity before 5.15 s). I guess the activity depends on the actual mouse movement, so it's hard to say whether the activity matches your mouse movement at that time. Its wait behavior looks pretty much like one would expect, I suppose: It waited 294 times on the "cursor semaphore" for a total of 9.74 s and 4 times on the "floating overlays lock" for a total of 0.004 s. So the frozen cursor would either point to the event or the drawing side of things. * I noticed that there's a total wait time of 1 min 1 s (1159 times) on the "ports list" mutex, which is a serious problem. I'm not sure, if I messed that up when reworking the kernel locking or if it was already broken before. From a quick scan of the ports code one might think that locking the port's lock while holding `sPortsLock` (particularly in `get_locked_port()` and `set_port_owner()`) could be the reason, but none of the port locks actually shows up with a significant amount of wait time ("system:roster" with a total of 0.0001 s, four other locks with even less). So something else must be the cause. At any rate, I believe the enormous contention on the "ports list" lock is the cause for the visual freeze, since port messages cannot be sent and threads cannot start waiting on a port without first acquiring this lock. And port messaging is kind of the backbone of communication with and within the app server. * I also noticed that there are 397 waits and a total wait time of 7.44 s on the "USB Stack Allocator" mutex. This sounds relatively much for a mutex and might be something that should be optimized. CCing mmlr for good measure. -- Ticket URL: <http://dev.haiku-os.org/ticket/8007#comment:14> Haiku <http://dev.haiku-os.org> Haiku - the operating system.