Jump to content
  • Advertisement
Sign in to follow this  
ginkeq

Threads problem

This topic is 3809 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by ginkeq
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.
If they "closed" the process, it won't be in task manager because the process has terminated.

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by ginkeq
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)?
Yes, 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.

Quote:
Original post by ginkeq
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.
A 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.
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by Evil Steve
Quote:
Original post by ginkeq
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)?
Yes, 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.

Quote:
Original post by ginkeq
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.
A 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.
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

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!