diff options
| author | Michele Calgaro <michele.calgaro@yahoo.it> | 2025-06-21 21:49:09 +0900 |
|---|---|---|
| committer | Michele Calgaro <michele.calgaro@yahoo.it> | 2025-06-30 21:44:39 +0900 |
| commit | d4b3598f25774c1f1c33e000d421e740970fb369 (patch) | |
| tree | 43b4b56c18dfc3febc193f735075e113bed84ac9 /kdesktop/DESIGN | |
| parent | a16753500bb5ca90db10bd98d59c6b5ab662e29b (diff) | |
| download | tdebase-d4b3598f.tar.gz tdebase-d4b3598f.zip | |
kdesktop: fix deadlock condition between kdesktop and kdesktop lock.
The logic to handle communication with kdesktop_lock is now running
completely in a separate thread and event loop, meaning the main GUI
thread remains responsive all the time and can handle interaction with
X11, DCOP and DBUS calls. This resolves issue #589.
The commit also solves the first problem reported in issue #640 and
loosely related to PR #526.
Signed-off-by: Michele Calgaro <michele.calgaro@yahoo.it>
(cherry picked from commit 409442c1ea8f167485642fbdb3494ff58900966f)
Diffstat (limited to 'kdesktop/DESIGN')
| -rw-r--r-- | kdesktop/DESIGN | 13 |
1 files changed, 13 insertions, 0 deletions
diff --git a/kdesktop/DESIGN b/kdesktop/DESIGN index 7e195378f..170a86a75 100644 --- a/kdesktop/DESIGN +++ b/kdesktop/DESIGN @@ -124,3 +124,16 @@ kdesktop_lock to kdesktop communication: - TTIN: the lock process is ready. This is sent after the process has been created/respawned - USR2: the lock/screensaver has been activated - USR1: the lock/screensaver has been unlocked/stopped + +Communication is handled by the screen saver engine defined in 'lockeng.{h,cpp}'. +The engine is split into two parts, the 'SaverEngine' running in the GUI thread and +the 'SaverEngineEventHandler' running in a separate thread and eventloop. +The 'SaverEngine' handles communication with X11, DCOP and DBUS while the +'SaverEngineEventHandler' handles communication with the actual lock process. +Several actions require cooperation of the two parts, so in various methods +there will be inter-thread calls (using timers or by emitting signals) to +trigger the other side remaining logic. +This complex design is necessary to avoid blocking the main GUI application event loop, +which has several tasks to manage and therefore can't affort to wait in a suspended state. +This was previously leading to deadlock when DCOP calls where executed on the secondary +thread/eventloop, for example when changing desktop while the lock process was restarting. |