From f916621d72b9804a3ef4bd83e485fe81bb876dab Mon Sep 17 00:00:00 2001
From: Luca Bacci <luca.bacci982@gmail.com>
Date: Thu, 31 Aug 2023 21:58:17 +0200
Subject: [PATCH] gthread-win32: Clean up GPrivate data in all cases

---
 glib/glib-init.c     |  5 +++++
 glib/gthread-win32.c | 22 ----------------------
 glib/tests/private.c | 13 -------------
 3 files changed, 5 insertions(+), 35 deletions(-)

diff --git a/glib/glib-init.c b/glib/glib-init.c
index e9017942f..7d4a4d5d9 100644
--- a/glib/glib-init.c
+++ b/glib/glib-init.c
@@ -489,6 +489,11 @@ glib_priv_tls_callback (LPVOID hinstance,
       glib_dll = hinstance;
       tls_callback_invoked = TRUE;
       break;
+    case DLL_THREAD_DETACH:
+#ifdef THREADS_WIN32
+      g_thread_win32_thread_detach ();
+#endif
+      break;
     case DLL_PROCESS_DETACH:
       glib_win32_deinit (reserved == NULL);
       break;
diff --git a/glib/gthread-win32.c b/glib/gthread-win32.c
index 58e244ebe..4d768eb67 100644
--- a/glib/gthread-win32.c
+++ b/glib/gthread-win32.c
@@ -424,28 +424,6 @@ g_system_thread_free (GRealThread *thread)
 void
 g_system_thread_exit (void)
 {
-  /* In static compilation, DllMain doesn't exist and so DLL_THREAD_DETACH
-   * case is never called and thread destroy notifications are not triggered.
-   * To ensure that notifications are correctly triggered in static
-   * compilation mode, we call directly the "detach" function here right
-   * before terminating the thread.
-   * As all win32 threads initialized through the glib API are run through
-   * the same proxy function g_thread_win32_proxy() which calls systematically
-   * g_system_thread_exit() when finishing, we obtain the same behavior as
-   * with dynamic compilation.
-   *
-   * WARNING: unfortunately this mechanism cannot work with threads created
-   * directly from the Windows API using CreateThread() or _beginthread/ex().
-   * It only works with threads created by using the glib API with
-   * g_system_thread_new(). If users need absolutely to use a thread NOT
-   * created with glib API under Windows and in static compilation mode, they
-   * should not use glib functions within their thread or they may encounter
-   * memory leaks when the thread finishes.
-   */
-#ifdef GLIB_STATIC_COMPILATION
-  g_thread_win32_thread_detach ();
-#endif
-
   _endthreadex (0);
 }
 
diff --git a/glib/tests/private.c b/glib/tests/private.c
index 37f7761a0..424c34b86 100644
--- a/glib/tests/private.c
+++ b/glib/tests/private.c
@@ -148,19 +148,6 @@ test_private3 (void)
     thread = (HANDLE) _beginthreadex (NULL, 0, private3_func, NULL, 0, &ignore);
     WaitForSingleObject (thread, INFINITE);
     CloseHandle (thread);
-
-    /* FIXME: with static compilation on Windows this test will fail because
-     * it is mixing up glib threads with Microsoft native thread API. See
-     * comment in gthread-win32.c for g_system_thread_exit() implementation.
-     * Fix is not straightforward, possible solution could be to use FLS
-     * functions (instead of TLS) as proposed in
-     * https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1655
-     */
-    if (!private3_freed)
-      {
-        g_test_skip ("FIXME: GPrivate with native win32 thread");
-        return;
-      }
   }
 #else
   {