Threads problem
Author
What would cause a process that uses threads to somehow stay in memory after the user closes that process? The process wouldn't be visible to the user but it is in task manager etc.
Quote:Original post by ginkeqIf they "closed" the process, it won't be in task manager because the process has terminated.
What would cause a process that uses threads to somehow stay in memory after the user closes that process? The process wouldn't be visible to the user but it is in task manager etc.
A process remains in memory until all threads in the process have terminated.
So, as Solias said, if you just close the window, and that causes you to break out of main() and your main thread to terminate, if other threads are running, the process won't terminate.
As an absolute last resort, you can use TerminateThread to kill off a thread - but that's an extremely bad idea and should only be done as a last resort. You should signal the thread to exit (By setting an event, a global volatile bool, or some other method), then wait a reasonable time, then if the thread still hasn't ended, use TerminateThread to kill it before exiting main.
ExitProcess will also shut down all of your threads, but isn't recommended for the same reasons as TerminateThread. If you still have threads running when you're trying to have your app quit, then you need to exercise more control over the lifetime of your threads. Make sure you have a way of communicating with each thread, because you will need to use this method to tell a thread to shut down.
Author
What if the thread was creating by third party code where you can not control it?
How do you deal with that? Shouldn't that code provide a method to stop running itself (a close operation)?
Also, this does involve creating a window (which the thread is running/updating). I am using C# .NET, but how can I just say, check if this window is open and close it if so? That is probably Windows API territory, right?
i believe it is like this, mainapp thread calls method on third party code, third party code spawns its own thread/window and mainapp resumes execution.
How do you deal with that? Shouldn't that code provide a method to stop running itself (a close operation)?
Also, this does involve creating a window (which the thread is running/updating). I am using C# .NET, but how can I just say, check if this window is open and close it if so? That is probably Windows API territory, right?
i believe it is like this, mainapp thread calls method on third party code, third party code spawns its own thread/window and mainapp resumes execution.
Quote:Original post by ginkeqYes, the library should provide a way to kill the thread, or it should kill itself. If it doesn't, the library is broken, or you're using it wrongly.
What if the thread was creating by third party code where you can not control it?
How do you deal with that? Shouldn't that code provide a method to stop running itself (a close operation)?
Quote:Original post by ginkeqA window has nothing to do with a thread. One thread can have 100 windows, or 0 windows. Just because the window is closed, does not mean the thread will be terminated.
Also, this does involve creating a window (which the thread is running/updating). I am using C# .NET, but how can I just say, check if this window is open and close it if so? That is probably Windows API territory, right?
i believe it is like this, mainapp thread calls method on third party code, third party code spawns its own thread/window and mainapp resumes execution.
Closing the window will not necessarily kill the thread that spawned it - that will only be the case if the code is set up to exit the window loop when the window is destroyed, and then to exit the thread.
In C# (and .net in general), you can use "IsBackground" property of Thread to make sure the thread is automatically terminated once all foreground threads have been terminated.
Author
Quote:Original post by Evil SteveQuote:Original post by ginkeqYes, the library should provide a way to kill the thread, or it should kill itself. If it doesn't, the library is broken, or you're using it wrongly.
What if the thread was creating by third party code where you can not control it?
How do you deal with that? Shouldn't that code provide a method to stop running itself (a close operation)?Quote:Original post by ginkeqA window has nothing to do with a thread. One thread can have 100 windows, or 0 windows. Just because the window is closed, does not mean the thread will be terminated.
Also, this does involve creating a window (which the thread is running/updating). I am using C# .NET, but how can I just say, check if this window is open and close it if so? That is probably Windows API territory, right?
i believe it is like this, mainapp thread calls method on third party code, third party code spawns its own thread/window and mainapp resumes execution.
Closing the window will not necessarily kill the thread that spawned it - that will only be the case if the code is set up to exit the window loop when the window is destroyed, and then to exit the thread.
Closing the window does kill the thread though. Unfortunately I can't find the window really.
Also I dont have access to this thread but I can see one is created in Spy++.
Is there a .NET equivalent of calling TerminateProcess on the current process? Seems like the only reasonable solution atm
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
