node-gtk 4.0.0 → 4.0.1

package/lib/loop.js

@@ -45,10 +45,22 @@ function start() {
  * macrotask lets the module's top-level microtask return first, so the queue
  * drains and the loop integration takes over from a clean (non-nested) state.
  *
+ * We defer with setTimeout, NOT setImmediate. A setImmediate callback runs
+ * *inside* Node's immediate-processing machinery (native CheckImmediate ->
+ * processImmediate). Because `run` never returns (it blocks in the GLib main
+ * loop until the app quits), CheckImmediate never reaches the code that stops
+ * Node's private immediate uv_idle handle, so that handle stays active forever.
+ * An active idle handle pins uv_backend_timeout() at 0, which makes the nested
+ * uv-in-GLib loop busy-spin at 100% CPU (worse on Node 26 / libuv 1.52, where
+ * the immediate's wakeup eventfd also stays signalled). A one-shot timer is
+ * removed from libuv's timer heap before its callback runs, so blocking inside
+ * it leaves no libuv state active and the loop can sleep normally. See #477.
+ *
  * Under CommonJS (and inside signal callbacks) we are not in a microtask, so we
  * run synchronously and preserve the original blocking semantics exactly.
  *
  * https://github.com/romgrk/node-gtk/issues/442
+ * https://github.com/romgrk/node-gtk/issues/477
  *
  * Returns the native call's result when run synchronously (so e.g.
  * `const status = app.run()` keeps working under CommonJS); returns undefined
@@ -64,7 +76,7 @@ function runLoopEntry(run) {
   start()
 
   if (internal.IsRunningMicrotasks()) {
-    setImmediate(run)
+    setTimeout(run, 0)
     return undefined
   }
   return run()

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "node-gtk",
-  "version": "4.0.0",
+  "version": "4.0.1",
   "description": "GNOME Gtk+ bindings for NodeJS",
   "main": "lib/index.js",
   "exports": {