How long is a thread active?

[Wanderer82]

Hello

When I start a thread and detach it and then my main program is closed before the thread has finished, will the thread just be terminated as well? Are there any things to consider when doing this?

Thanks,
Thomas

[doublemax]

When I start a thread and detach it and then my main program is closed before the thread has finished, will the thread just be terminated as well?

No. If the thread is still running, it will look like your app terminated, but it will keep running and remain as a zombie in the task manager.

If you're using a detached thread, you should delete it first. However, with detached threads there is always the danger that you access the thread through a pointer immediately after the thread already deleted itself. Therefore, you'll need a wxMutex or wxCriticalSection to avoid potential crashes.

The the MyFrame::OnClose() method from the sample code.
https://docs.wxwidgets.org/trunk/classwx_thread.html

[ONEEYEMAN]

Hi,
Or check the documentation, which also have sample code on crating a/working with thread.

Thank you.

[Wanderer82]

Well, I have to say, that's a bit too complicated for me with wxMutex etc. And I didn't use wxThread but the std <thread>.

But in the meantime I have tried to put a loop inside my detached thread that never ends. Although the thread should never end, after terminating my main app I can't see any process in the task manager as you, Doublemax, said that there would be one. So I wonder why this isn't the case. Does it have to do something maybe that I start the thread inside a function that I call from my main app? And then I return from the function. Maybe this is what ends / deletes my thread as well?

[doublemax]

Does it have to do something maybe that I start the thread inside a function that I call from my main app? And then I return from the function. Maybe this is what ends / deletes my thread as well?

Can you show that code?

[Wanderer82]

Sure. This is the separate .cpp file (outside the main app) with the functions (shortened):

Code: Select all

#include "Printer_Install.h"
#include <thread>

int IP_check;

void threadIP_Check()
{
    if(wxDirExists("\\\\UNT-Server01\\userdata\\" + _User.Username)) //This is the actual IP-check
    {
	IP_check = 0;
    }
       	
     //This is the test loop to check whether there is a process after terminating the main app and not actively terminating this thread
     int i = 0;
     while (i == 0)
     {
        wxMessageBox("Test");
     }
}

void Printer_Install()
{
    //Check connection to UNT-server
    IP_check = 1;

    thread funcTest1(threadIP_Check);
    funcTest1.detach();
    
    {wxBusyInfo wait("Checking connection to server...");
    Sleep(2000);
    }
    
    if(IP_check == 1)
    {
    	wxBusyInfo wait2("There seems to be no connection, the printer installation is terminated...");
        Sleep(4000);
        return; //After this return, I manually close the main app and there is no process in the task manager anymore
    }

In the main app, I just call Printer_Install() and when it returns I do a Close() and return; inside the main app to terminate it.

EDIT:

I have an additional question: Shouldn't there be a separate sub-process in the task-manager for every started thread? I ask because I can only see one process when the thread is running.

[doublemax]

Code: Select all

     //This is the test loop to check whether there is a process after terminating the main app and not actively terminating this thread
     int i = 0;
     while (i == 0)
     {
        wxMessageBox("Test");
     }
}

Are you sure the thread is still running? If yes, it should display the messagebox and re-open it every time you close it. Can you replace the
wxMessageBox with wxLogDebug("test") and use a tool like DebugView to check it the output appears? (The app must be built in debug mode for that)
https://docs.microsoft.com/en-us/sysint ... /debugview

I have an additional question: Shouldn't there be a separate sub-process in the task-manager for every started thread?

No. But there is also a column for the number of threads an application uses.

[Wanderer82]

Well the question wasn't, if the thread is still running but how could it be that it isn't running anymore because you said that it should continue running even when the main app terminates. And to answer your question: No, there is no message box showing up as soon as my main app is terminated. So the question is: why is the thread also terminated although it shouldn't.

Well, I tried replacing the wxMessageBox with wxLogDebug. The only difference is that the program now gets blocked and it takes quite some time until the main app terminates because wxLogDebug doesn't wait for "OK" before it gives out the next message. But eventually the main app still closes and there is no other process in the task manager.

I didn't manage to use DebugView though. There is nothing logged. I should only start DebugView and then start my app in CodeBlocks in debug mode and DebugView should start capturing things, right?

Btw: I don't know where you see the thread count in the task manager...

[doublemax]

Well the question wasn't, if the thread is still running but how could it be that it isn't running anymore because you said that it should continue running even when the main app terminates. And to answer your question: No, there is no message box showing up as soon as my main app is terminated. So the question is: why is the thread also terminated although it shouldn't.

Sorry, no idea. Maybe stl threads behave differently. I only use wxThread and based on my experience the app stays in the task manager if there is a thread still running.

I didn't manage to use DebugView though. There is nothing logged. I should only start DebugView and then start my app in CodeBlocks in debug mode and DebugView should start capturing things, right?

If you're running from an IDE, it should catch the debug output (instead of wxLogDebug). But i don't know if CB does that. Try running the app with Build->Run instead of "Debug -> Start". Also, put a short sleep() after wxLogDebug to avoid hogging the CPU.

Btw: I don't know where you see the thread count in the task manager...

Under "View" should be an option to select which columns are visible.

[Wanderer82]

Ok, now if I start the app normally from the IDE the debugger catches the events. I put a Sleep now and in the debugger I see that "test" was caught four times and then the main app was terminated by me and the "test" appearances stop. So yes, the thread seems to be terminated as well.

As I read on the internet this is the usual behavior of threads. The OS will clean up all threads when the main app is terminated. Well, usually it will but it is not a 100% sure.

Actually my problem is that the function wxDirExists inside my thread takes too long to get a result if the server is not reachable. So I wonder if there isn't another option to cut this time. Why is wxDirExists waiting so long (20-30 seconds) to establish a connection to a directory? Is there any option to cancel this function after a specific time has passed? Or can I somehow give a lifetime limit in seconds to the thread until it automatically is killed? In this specific case it should do no harm to kill the process of looking for a directory.

[doublemax]

I would write the "waiting" code like this (written without compile or syntax check, but you should get the idea):

Code: Select all

    thread funcTest1(threadIP_Check);
    funcTest1.detach();
    
    { // extra block to make sure the wxProgressDialog gets destroyed before displaying anything else
      wxProgressDialog dlg("Printer installation", "Checking connection to server...", 100, this, wxPD_APP_MODAL|wxPD_CAN_ABORT);
      dlg.Show();
      
      bool abort = false;
      long endtime = ::wxGetLocalTime() + 10 * 60;    // wait at most 10 seconds
      while( abort == false && IP_check == 1 && endtime > ::wxGetLocalTime() {
        abort = !dlg.Pulse();
        ::wxMilliSleep(200);
      }
    }

[Wanderer82]

Now I don't quite understand what the rewritten code for the "waiting" should help for my problem. The problem is that the function wxDirExists inside my thread should be terminated after 1-2 seconds and not wait for 20-30 seconds. Because the main problem is that this function won't have finished by the time the user exits the main app (which he will just after the printer install has been aborted). So I think my main problem hasn't changed just by using a wxProgressDialog instead of Sleep() or maybe I just don't get the point

[doublemax]

Now I don't quite understand what the rewritten code for the "waiting" should help for my problem. The problem is that the function wxDirExists inside my thread should be terminated after 1-2 seconds and not wait for 20-30 seconds.

That's probably a system timeout. If you had a link to that directory on the desktop and you tried to open it, you should get the same delay. But as you've already established that the thread is properly terminated when the app terminates, i don't see a problem here.

The advantage here is that you can control how long the app should wait. Using wxProgressDialog is more a cosmetic change, as it looks nicer, doesn't block the GUI, and shows an animation.