0

I am new in multithreading, and trying to create a application that supports multithreading. But I want to stop and particular thread. I saw rhe terminate() function but it will stop all the threads.

std::thread at(receivedfxn, sock);
at.detach();

This is my thread which I want to stop so can anyone please tell me the solution.

Chandrapal Singh Jhala
  • 235
  • 1
  • 4
  • 16
  • Take a look at https://stackoverflow.com/questions/12207684/how-do-i-terminate-a-thread-in-c11 -- It doesn't seem like you can. Why would you do that anyway? – AlexG Jul 17 '18 at 17:12
  • Why would you want to stop a thread? It's potentially dangerous and `std::thread` intentionally doesn't provide that option. – DeiDei Jul 17 '18 at 17:13
  • It is possible only by calling OS dependent function like [TerminateThread](https://learn.microsoft.com/en-us/windows/desktop/api/processthreadsapi/nf-processthreadsapi-terminatethread). @DeiDei using std::find or memcpy etc. is potentially dangerous but we are using them anyway, what the point in your comment. – Logman Jul 17 '18 at 17:34
  • 1
    @Logman Everything has a risk, but keep scale in mind. The difference in the risk between `std::find` or `memcpy` and terminating a running thread is huge. Terminating a thread should be a last resort. Prefer to politely ask the running thread to return. – user4581301 Jul 17 '18 at 17:51
  • @user4581301 I disagree. Killing a thread may or may not be potentially dangerous, but we can not say how dangerous it is until we know environment, code, etc. In some system it may be perfectly fine to kill a thread and there will be no side effects to it. In multithread environment using functions like `std::find` or `memcpy` may be more dangerous then killing a thread because error may occurred in unexpected place. I just want to say that everything may be potentially dangerous until you know what you are doing, and for that reason answers like "it's evil", and not providing why are stupid. – Logman Jul 17 '18 at 20:13

1 Answers1

1

In general, there is only one correct way in which a thread should end in normal program flow, and that is by the thread function returning.

I don't know what your receivedfxn does exactly, but I suspect it will wait for some data to arrive at sock and then return!? The natural way to stop this thread would then be to close the socket which in turn should cause any pending receive operations to be interrupted and return…

Michael Kenzel
  • 15,508
  • 2
  • 30
  • 39
  • 1
    This is a poor idea closing other thread's socket in a multi-threaded application. – Maxim Egorushkin Jul 17 '18 at 17:17
  • Care to elaborate why? – Michael Kenzel Jul 17 '18 at 17:20
  • By the time you close other thread's socket, it may have been already closed and re-opened by another thread, so you end up closing wrong file descriptor. Race condition. – Maxim Egorushkin Jul 17 '18 at 17:21
  • If such a thing can happen, that would obviously be a grave design error in the program in general. Obviously, you will need to correctly manage ownership and lifetime of resources. However, I don't see how you can generally say that a socket must never be closed while a thread is waiting for data. What other approach would you suggest to cancel a pending `recv()` operation? – Michael Kenzel Jul 17 '18 at 17:26
  • Non-blocking sockets with an event loop. – Maxim Egorushkin Jul 17 '18 at 17:27
  • 3
    Shame about the downvotes because the first sentence here is what's really important: Threads in a multi-threaded program always should _cooperate_ with one another. In the ideal case, A thread would terminate only when (a) its work is done, or (b) some other thread sent a message requesting that it shut itself down. Of course there is also (c) shut itself down because an unrecoverable error occurred... – Solomon Slow Jul 17 '18 at 17:27
  • I agree @jameslarge, and don't we additionally have (d) the main progam exits or something similar, it closes the socket, and all threads using the socket must terminate? – Klaas van Aarsen Jul 17 '18 at 17:37
  • @MaximEgorushkin well, that's a completely different design then. Exploring the tradeoff between event-based and polling-based approaches goes way beyond what was asked here. Sorry, but I don't see how "use non-blocking sockets" is a useful response here… – Michael Kenzel Jul 17 '18 at 17:43