From 7e3a84fc858f86644a566c1b1ec084e109b3e429 Mon Sep 17 00:00:00 2001 From: "Adam D. Ruppe" Date: Sat, 4 Mar 2023 18:56:28 -0500 Subject: [PATCH] document loop pitfall that can lead to MsgWaitForMultipleObjectsEx failing --- minigui.d | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) diff --git a/minigui.d b/minigui.d index 6278610..d639b37 100644 --- a/minigui.d +++ b/minigui.d @@ -8518,6 +8518,49 @@ class Window : Widget { Blocks until this window is closed. + Bugs: + + $(PITFALL + You should always have one event loop live for your application. + If you make two windows in sequence, the second call to loop (or + simpledisplay's [SimpleWindow.eventLoop], upon which this is built) + might fail: + + --- + // don't do this! + auto window = new Window(); + window.loop(); + + // or new Window or new MainWindow, all the same + auto window2 = new SimpleWindow(); + window2.eventLoop(0); // problematic! might crash + --- + + simpledisplay's current implementation assumes that final cleanup is + done when the event loop refcount reaches zero. So after the first + eventLoop returns, when there isn't already another one active, it assumes + the program will exit soon and cleans up. + + This is arguably a bug that it doesn't reinitialize, and I'll probably change + it eventually, but in the mean time, there's an easy solution: + + --- + // do this + EventLoop mainEventLoop = EventLoop.get; // just add this line + + auto window = new Window(); + window.loop(); + + // or any other type of Window etc. + auto window2 = new Window(); + window2.loop(); // perfectly fine since mainEventLoop still alive + --- + + By adding a top-level reference to the event loop, it ensures the final cleanup + is not performed until it goes out of scope too, letting the individual window loops + work without trouble despite the bug. + ) + History: The [BlockingMode] parameter was added on December 8, 2021. The default behavior is to block until the application quits