4d1c422802
of locking before processing the message (single/all window lock) -> in most message cases, I could comment out the unlocking/locking which switched to the different lock, because the required lock is now already held, this removes some race conditions which were commented in the code already * EventDispatcher::SetDragMessage() didn't lock the object, this would have been bad if multiple windows tried to set a drag bitmap at once * the Desktop object keeps track of mouse position and pressed buttons, so that it doesn't need to lock the EventDispatcher for sending fake mouse moves to windows on show/hide of windows (solves some cases of possible dead locks with the new locking strategy) * the keyboard EventFilter switches the current workspace asynchrnously from the Desktop thread (another source of possible deadlocks) * the "reader is trying to become writer" check in MultiLocker is only used in DEBUG mode now As a summary: It would be nice if ServerWindow used a readlock for all messages it processes itself, and forwards all messages for which it needs a write lock to the Desktop thread. All cases where either the Desktop or the ServerWindow mess with the EventDispatcher are possible sources of deadlocks. This is solved right now by making sure that the lock is released before using the EventDispatcher. I have not observed any deadlocks while switching workspaces and launching many apps anymore, neither crashes. But I have not tested extensively except for in the test environment. That being said, I could reproduce the problems on first try before in Haiku. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22410 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
||
|---|---|---|
| .. | ||
| app | ||
| debug | ||
| input | ||
| media | ||
| media_addon | ||
| midi | ||
| net | ||
| power | ||
| registrar | ||
| services_daemon | ||
| syslog_daemon | ||
| Jamfile | ||