Thread overrides?

Is that possible? I imagine it is, just as overriding other functions is possible.

Here's my situation:
I have many functions that perform various tasks with varied types of loops all at different times.
I want to be able to terminate a thread, properly, without having to custom write in a check in the varied loops of every single threaded function , just so that it terminates properly. (Since everyone warns to stay away from TerminateThread(HANDLE) ).

Here's my idea:
Have a function such as:

Code:

---

int myOverride(LPVOID) { return 0; }

---

Simple as that, and use the address of this function to override the functions that are running.
I have a mapping class/system that manages thread ID's, and thus, I can easily SuspendThread(HANDLE) at any time, and this works great, however, the thread is still existant in memory, and that's not good.
so the next step is figure out how to override that suspended thread, with the one above.... and I was hoping someone could point me in the right direction for that.


I have played with OpenGL hooking, and written very very basic FARPROC hooks that patch the address of a function to that of my own, which allows me to execute my own code within the address space of that function. So I suppose my problem with this, is I'm not sure how to do that for my OWN DLL, since the functions I've played with are always in an external DLL- of which I cannot see the code for. Not to mention, the functions I've overwritten before, are not threaded, which makes this situation all the more... interesting. Since I can have multiple dynamically allocated references to a single function - thus I can't simply override just the original function, is that not correct? I would imagine I need to override the specific thread that's running based on it's address in memory.... And that lead's to a further question.... If a thread is suspended, and then overriden, will resuming it actually execute, or just crash?

I saw this: http://www.codeguru.com/cpp/misc/mis...cle.php/c3793/
and it appears to do what I'm thinking of(Notably the Attach and Detach functions), but I haven't tried it yet because I'm thinking you guys would have better insight into this than myself in conjunction with an untested web link.... And I'd rather not waste time needlessly. Not to mention, I'd like to venture this path with my own code, not someone elses.

Any help is greatly appreciated....

Ehh screw it, I'm gonna use TerminateThread. It hasn't caused any problems yet, even though everyone says it will.

There's no way I'm coding in an event checker into every single loop inside of every single threaded function. The proper way blows, TerminateThread is sexy.



However, I'm still interested in the above information if anyone knows anything on it... That would be preferable to TerminateThread, but atleast TerminateThread works for now.

Quote:

---

Originally Posted by dcyuri7

Ehh screw it, I'm gonna use TerminateThread. It hasn't caused any problems yet, even though everyone says it will.

---

Do you know the reasons why TerminateThread can cause problems?

according to msdn:

Quote:

---

the target thread has no chance to execute any user-mode code. DLLs attached to the thread are not notified that the thread is terminating. The system frees the thread's initial stack.

---

Quote:

---

If the target thread owns a critical section, the critical section will not be released.
If the target thread is allocating memory from the heap, the heap lock will not be released.
If the target thread is executing certain kernel32 calls when it is terminated, the kernel32 state for the thread's process could be inconsistent.
If the target thread is manipulating the global state of a shared DLL, the state of the DLL could be destroyed, affecting other users of the DLL.

---

These two are my only concern:

Quote:

---

If the target thread owns a critical section, the critical section will not be released.
If the target thread is allocating memory from the heap, the heap lock will not be released.

---

Quote:

---

Originally Posted by dcyuri7

These two are my only concern

---

I would hate to see you get into this bad habit of using terminate thread. These maybe your only concerns today, but what about code maintenance?

Another developer (or you yourself) could add code in the future that would fail miserably if terminate thread is used. Most likely new code would appear to work, but end up with spurious failures that could be difficult to track down. It would be a real drag for the person doing the maintenance to have to go back in and add the code for the thread to exit cleanly.

A basic tenet of programming is to clean up resources after you are finished with them. Terminate thread generally precludes this from happening.

Hey thanks for the reply.

And I completely agree, however finding a resolution to Tedious Programming is quite the question it seems. I'll have to try out many different things and see what I can figure out. I still like my original idea above, to overwrite the threaded function as needed, and simply have it return (thus destructing correclty - i assume so, that is? )

That said, I am open for theories if anyone has any. I really do not want to have to custom write event checking for over 20 very, very, different funcitons. (some have up to 4 'For' loops, and others have 'While' loops, which = very tedious - especially for updating.)

I strive for efficiency, and to write ennificent code just makes me feel like...... Idunno, it's just freakin awful.

I do appreciate your input, and I'll continue to research this in hopes of finding a programattic resolution. C++ is powerful, and can accomplish almost anything. And in this regard, I have a strong feeling there is a way for me to bypass this issue. The problem is finding someone who has done it, so that it can be researched....As I am apparently not quite capable of developing such a thing, solo. =/

Quote:

---

Originally Posted by dcyuri7

I'm gonna use TerminateThread. It hasn't caused any problems yet, even though everyone says it will.

There's no way I'm coding in an event checker into every single loop inside of every single threaded function. The proper way blows, TerminateThread is sexy.

---

The statement should be decrypted this way:

• I like it done fast. Result never matters.
• Trouble never exists. Until it becomes really visible.

Quote:

---

Here's my idea:
Have a function such as:

Code:

---

int myOverride(LPVOID) { return 0; }

---

Simple as that, and use the address of this function to override the functions that are running.

---

Quote:

---

However, I'm still interested in the above information if anyone knows anything on it... That would be preferable to TerminateThread, but atleast TerminateThread works for now.

---

I think you are very far from real understanding of what a thread is and how its code gets executed. :) Even if you could manage to override a thread proc after thread start, the thread never would switch to execute the new function code. :D

If you had quoted the correct portion of the above post, you would have read the statement "If a thread is suspended, and then overriden, will resuming it actually execute, or just crash?".

I don't suppose you read that quote above,huh..?

I'll decrypt it for you.

• That was a question
• Your input was requested - in a kind way.

Quote:

---

think you are very far from real understanding of what a thread is and how its code gets executed

---

Boy I do wonder if that could be why I'm here? Geez, that would just make your post merely a pointless expression of the obvious.

Quote:

---

I like it done fast. Result never matters.

---

Wouldn't that make this thread redundant, metaphorically speaking, since that was the original reason for posting? (Hint: Answer is yes, and possibly a slap on the face too - backside of left hand of course)

Quote:

---

Trouble never exists. Until it becomes really visible.

---

Now this is the only thing about me that you have correctly diagnosed. 50% true, and I enjoy living my life this way, thanks you. In fact, I have halted my programming of my project due to this problem, so that I can resolve it. I would say that constitutes as an extremely early attempt in fixing trouble than, as you put it, "really visible" - since killing thread's is the smallest thing to worry about in a project such as mine. Atleast I am attempting programming correctly, and yet you have the time to let me know of your poorly perceived daignoses of my habits. That said, screw off hoe :)

To be equal in measure of manner as that of you in your post, I will state blatantly that you sir are rude, and I do not wish to speak with you further as it is not beneficial, in spirit, mind, nor is it even in the slightest way relative to the purpose of a forum. In fact it deminishes that purpose, and fuels the one of many poor lifeless angry people. If you wish to be a garden troll, go join gamedeception.net forums. You'll fit right in there.

Thanks anyway, and good riddance. :)

Well, it sounds like I have over stayed my welcome here. I am going to go ahead and be inactive on this thread, and just use TerminateThread until I find myself a fix for it.

I appreciate everyone's, except the troll of course, input here. If nothing else, it has helped me come up with some ideas for resolutions, and what better than that. So thanks guys.

Quote:

---

Originally Posted by dcyuri7

If you had quoted the correct portion of the above post, you would have read the statement "If a thread is suspended, and then overriden, will resuming it actually execute, or just crash?".

I don't suppose you read that quote above,huh..?

I'll decrypt it for you.

---

Quote:

---

Originally Posted by dcyuri7

I appreciate everyone's, except the troll of course, input here.

---

It sounds (looks) childish: "OK I will take my toys and go and play elsewhere"; it is not a good approach to learning.
Also, I do not think you have to be sardonic and insulting.
To get an answer to any question, you have to know first what question to ask. I see attempts to give you an advice by giving you hints.
Once you well understand basics I am sure you will understand why insisting on using bad approach after being advised to do otherwise, can be frustrating to espondents.
If you ask question and ignore good advice wht is the point of asking question anyway?

Lest us start from the top:

You asked how to override a thread. Could you define Thread overrides?

You see, the way you have asked question, suggests what you need to learn more about C++ programming and Windows OS first, before getting into a multithreading or API hooking.

API hooking and multithreading are two completely separated areas and have nothing in common.
API hooking It is not the same as C++ function override by declaring member function virtual.

From your post I gather, you may refer to a self-modifying code or API hooking. API hooking is possible but it has nothing to do with thread execution. API hooking is completely unnecessary for Windows application. It is being used sparingly in some diagnostic programs; it is dangerous. It replaces Windows exported function address contained in the system table with other address and causes each call to this function to be redirected.
Self modifying code would be possible for a program written in machine code.


Threads however are used to carry background pricessing of some sort of data and are never exported. In preemptive system (like Windows) newly spawned thread receives certain time slice from CPU independently of a main thread that spawned it.

It is your responsibility to terminate thread properly, using many available way of synchronization. Using TerminateThread is the last resort and if is needed it means that code is written in a very bad manner and should be revised.

You can find gazillions of samples showing how to properly write GUI or worker thread and how to synchronize execution of multiple threads. If you still have doubts after reading materials you will know what question to ask.