0

Is there any way to terminate a thread using the thread id or even getting a Thread object using a thread id ?

morbyosef
  • 113
  • 1
  • 9
  • 10
    It's almost never sensible to terminate a thread from outside the thread. Threads should end because their thread function returns. –  Nov 12 '18 at 19:27
  • What do you mean by thread id? – SergeyA Nov 12 '18 at 19:30
  • @NeilButterworth i do not agree with that. While it is better to allow process exit because they return from `main`, `kill -9` exists for a reason. There could very good reasons to terminate threads from outside forcefully. – SergeyA Nov 12 '18 at 19:31
  • 6
    @Sergey `kill` terminates processes, not threads. If you know of a good reason for terminating a thread in the way you suggest, that leaves the containing process in a known state, please describe it. –  Nov 12 '18 at 19:33
  • @SergeyA I mean the id of the specific thread. std::thread::id – morbyosef Nov 12 '18 at 19:33
  • @NeilButterworth I am well aware of that. I was hoping that you can see the analogy here, sorry if my intention wasn't clear. – SergeyA Nov 12 '18 at 19:33
  • @NeilButterworth I want to do that in order to check any scenario of dll injection to my process and in order to do that I want to check if there is any attached thread to my process – morbyosef Nov 12 '18 at 19:36
  • Not an exact dupe, but: https://stackoverflow.com/questions/12207684/how-do-i-terminate-a-thread-in-c11 –  Nov 12 '18 at 19:38
  • @NeilButterworth I know of a several. All of them relate to an architecture of an application which serves as a container of multiple unrelated threads. A typical web-server is a good example of the one. – SergeyA Nov 12 '18 at 19:39
  • *"check any scenario of dll injection to my process and in order to do that I want to check if there is any attached thread to my process"* - what does thread termination have to do with this? – user7860670 Nov 12 '18 at 19:40
  • 6
    @SergeyA You forgot about the part where the process should be in a known state. Terminating a thread leaks it's resources. And since you are in a multithreated context, mutex lock are included in that. – François Andrieux Nov 12 '18 at 19:40
  • @VTT I can find the id of the attached thread and then I want to terminate it. – morbyosef Nov 12 '18 at 19:42
  • @FrançoisAndrieux sometimes you have to sacrifice the known state. For example, you might be already exiting, but a misbehaving thread doesn't stop. It's better to cancel it. You also assume those threads share mutexes, and I haven't said that. – SergeyA Nov 12 '18 at 19:42
  • 2
    @Sergey Surely better to terminate the process. –  Nov 12 '18 at 19:43
  • dll injection does not necessary include any thread spawning and killing random threads makes no sense anyway – user7860670 Nov 12 '18 at 19:44
  • @NeilButterworth I already said above - the process is already terminating and thread is misbehaving and not exiting, for example, because it is stuck in the loop or long operation. – SergeyA Nov 12 '18 at 19:44
  • 4
    @SergeyA You've described a situation that worth a bug report, not a thread kill. – user7860670 Nov 12 '18 at 19:45
  • 2
    @Sergey The process can kill itself. Any looping threads cannot prevent a kill. Otherwise, the OS wouldn't work. –  Nov 12 '18 at 19:48
  • @VTT I already used this analogy - `kill -9` is a crude tool, but sometimes you have to use it. Same thing with thread cancellation - it is not preferred, but sometimes it is a lesser of evils. – SergeyA Nov 12 '18 at 19:49
  • @NeilButterworth think of the application as an OS. Same way OS manages processes, an app can manage it's own threads. On any rate, the mere existence of `pthread_cancel` (and the fact that OS implementors go signficant length to make it available) could be an indication that it has it's uses. I am also quite tired of this rather fruitless discussion. You are free to never use `pthread_cancel` in your whole life. – SergeyA Nov 12 '18 at 19:54
  • @VTT In my case I try to avoid this kind of dll injection so terminate the thread is the way that I found to do that. Do you have any other way to do that? I would like to get more options – morbyosef Nov 12 '18 at 19:55
  • 2
    @SergeyA, Re, "Think of the application as an OS..." That's a false analogy. The whole point of processes in an OS is that the OS keeps them _isolated_ from one another. The OS has privileged code that manages processes, keeps track of what resources they use, and cleans up after a process dies. Threads within a process are the exact opposite of isolated from each other: They share _everything_ except their CPU registers. And, there is no privileged, "kernel code" in a process that can keep track of what the threads have done or, can clean up after them when they go off the rails. – Solomon Slow Nov 12 '18 at 20:21

1 Answers1

-1

There is nothing you can do from std::thread::id alone. This is simply a unique representation of all currently running threads.

It's primary purpose is to be used as an index type for associative containers, so what you can do with it is to put it as a key into std::map or std::unordered_map, and than use it to lookup for std::thread object.

Once you have found the std::thread object, you can retrieve it's native_handle, and than use OS-specific mechanisms to stop the thread. For example, in Posix that would be pthread_cancel.

SergeyA
  • 61,605
  • 5
  • 78
  • 137