[C++/SHV] Cleaning up threads in DllMain?

[ikt]

Figure this is more of a general Windows API issue, but seeing as someone might have also dealt with a similar issue, this might be a decent place to ask.

Note: This is not about script threads.

 

So I have an additional std::thread running, which periodically checks a "heartbeat". When the game is running, the heartbeat is live, and nothing happens. If that goes away, the additional thread places a call to turn off a peripheral. Basically, it's to cancel the active force feedback effect when the game gets paused.

 

It works well, but breaks when I try to clean up the tread in DllMain, where it enters a deadlock and SHV can't deal with it. Sadly, ScriptHookV does not have a pre-Unload callback so I can clean up my leftover stuff.

This seems to be an unavoidable problem when dealing with ("permanent") threads in ScriptHookV scripts. Does anyone have any experience with this, and ways to not break DllMain's DLL_PROCESS_DETACH case?

Here's a snippet of very basic (pseudo? didn't compile)-code which should reproduce the issue:
 

#include <main.h>

#include <Windows.h>

#include <atomic>
#include <thread>

std::atomic_bool g_RunThread = true;

void ScriptMain()
{
    std::thread([]()
    {
        while(g_RunThread)
        {
            // Non-game thread be here
        }
    }).detach();

    // Game "thread"
    while(true)
    {
        // Script logic be here
        WAIT(0);
    }
}

BOOL APIENTRY DllMain(HMODULE hInstance, DWORD reason, LPVOID lpReserved)
{
    switch (reason)
    {
    case DLL_PROCESS_ATTACH:
        scriptRegister(hInstance, ScriptMain);
        break;
    case DLL_PROCESS_DETACH:
        g_RunThread = false; // This deadlocks
        scriptUnregister(hInstance);
        break;
    }
    return TRUE;
}

For clarity, this is entirely expected behavior as DllMain locks stuff and Microsoft is very clear no waiting-for-thread-stuff should happen in DllMain. I'm just wondering if there are alternatives that solve a similar issue, where one needs an additional thread that runs regardless of game run state.

For my specific problem (cancelling force feedback), it should be possible to hook an OnGamePaused function, but I have no idea where to start that. But it'd remove the need for the thread.

-----

 

Small update: Went with checking PAD::IS_CONTROL_PRESSED(0, eControl::ControlFrontendPause) which works fine. I suppose that's also the best solution - avoid threading stuff in DLL cleanup at all costs :x

Edited August 9 by ikt