warp the mouse to the primary screen. entering the primary screen causes the primary screen's window to be hidden. the deadlock occurs because hiding the window seems to post a message then wait for it to be handled (or possibly it won't send a message while a posted message is being handled). thread A locks the mutex, warps the mouse, the hides the window. thread B begins processing the mouse warp then tries to lock the mutex. thread A is waiting on the event loop owned by B while B is waiting on the mutex owned by A. this fix simply hides the window asynchronously. however, there may be other ways to cause a similar deadlock that have not been found. |
||
|---|---|---|
| .. | ||
| base | ||
| client | ||
| http | ||
| io | ||
| mt | ||
| net | ||
| platform | ||
| server | ||
| synergy | ||
| Makefile.am | ||