0

I have a UDP multicast receiver that will start an std::thread then detach() it to handle the receiving of messages, and it should be able to interrupt the blocking call when called upon. 

 void startThread()
{
    if(flagIsNotset)
    {
        //set flag
        std::thread t(&receiveData, this, socketDetails);
        t.detach();
    }
}


    void receiveData(socketDetails)
    {
       //initilaise socket
       //bind socket to interface
       //binds multicast address & port to interface

       while(true) 
       {
           //recvfrom(...)

           //handle received data
        }

       //prints a message to know that the thread has exited the while loop
       //unset flag
    }

    void interrupt()
    {
         //unset flag is shifted here after realizing it did not reach the end of receiveData() when closesocket was called for the first time.
         closesocket(s);
    }

everything was fine, I can receive UDP messages etc. but when interrupt is first called: it does not reach the message printing part & setting flag portion. when I shift the //set flag codes to interrupt(), I can confirm that for the first time (of calling interrupt() then startThread()), the message is not printed but on subsequent calls, it reached the end of the receiveData function as intended.

My question are as follows :

1) What happened to the first thread that was detached? is it stuck in recvfrom forever and was not interrupted by closesocket() ?

2) Will this cause memory leaking ? that is my primary concern...as I am unable to figure out the state of the first thread that was detached, will setting the thread t as a private member and calling the t::~thread() in interrupt() helps to ensure that the thread is terminated when interrupt is called?

3) Repeating startThread() and interrupt() does not seems to create a duplicate thread that is listening from the same socket. (i.e always receive one copy of the multicast message)

4) If there is any suggestions to improve this code, please feel free to comment.

randominstanceOfLivingThing
  • 16,873
  • 13
  • 49
  • 72
angelhalo
  • 131
  • 1
  • 1
  • 8
  • Are those functions thread safe? I couldn't convince myself that they are from quickly scanning the documentation.. – Jesper Juhl Aug 17 '16 at 19:22
  • which functions are you refering to ? iirc, using closesocket() to unblock a blocking call from recvfrom() was an idea i saw from http://stackoverflow.com/questions/8049677/stopping-a-receiver-thread-that-blocks-on-recv with my implementation, at any point of time, there is only one worker thread using this socket. the only exception is calling the closesocket() from the main thread. – angelhalo Aug 17 '16 at 20:48
  • `recvfrom` and `closesocket`. – Jesper Juhl Aug 17 '16 at 20:50
  • as far as i know, winsock2 is thread safe and detaching a thread to listen for data seems legit, with reference to : http://stackoverflow.com/questions/13983398/is-winsock2-thread-safe – angelhalo Aug 17 '16 at 21:01
  • Reading in a separate thread is perfectly fine. However, if `closesocket()` is not aborting a blocked `recvfrom()` (it should, at least on Windows), you could try re-writing the code to not rely on that behavior. Use `WSASocket()` with the `WSA_FLAG_OVERLAPPED` flag to create the socket, then use `WSARecvFrom()` instead of `recvfrom()` so you can associate the read with a `WSAOVERLAPPED` struct or an I/O Completion Port. You can then abort the read using `CancelIo/Ex()` before closing the socket. – Remy Lebeau Aug 18 '16 at 01:33

0 Answers0