8

I'm using a C++11 std::thread. Its main loop consists of a blocking recvfrom() call which listens for UDP packets arriving on a DATAGRAM socket, and some sophisticated code that parses the message and manipulates loads of STL containers in the process.

The thread belongs to a class (helloexchange), is started by the constructor and should be cancelled in the destructor. For obvious reasons, I do not want to forcefully terminate the thread, since this could currupt the data structures, which are partially located outside the class.

When using pthread instead of std::thread, there is the pthread_cancel method, which, in conjunction with pthread_setcancelstate, provides all the functionality I require: It will only cancel the thread while it's blocking in certain system calls, and the cancelling can be completely disabled for certain sections. The cancel is then performed once it's enabled again. This is a complete example of working pthread code:

#include <arpa/inet.h>
#include <unistd.h>
#include <iostream>
#include <sys/socket.h>
#include <sys/types.h>
#include <cstdio>
#include <pthread.h>
#include <net/if.h>
#include <ifaddrs.h>

int sock;

void *tfun(void *arg) {
    std::cout << "Thread running" << std::endl;
    while(true) {
        char buf[256];
        struct sockaddr_in addr;
        addr.sin_family = AF_INET;
        socklen_t addrlen = sizeof(addr);
        //allow cancelling the thread
        pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, NULL);

        //perform the blocking recvfrom syscall
        int size = recvfrom(sock, (void *) buf, sizeof(buf), 0,
            (struct sockaddr *) &addr, &addrlen);

        //disallow cancelling the thread
        pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL);

        if(size < 0) {
            perror("Could not receive packet");
            return NULL;
        } else {
            //process the packet in the most complex ways
            //you could imagine.
            std::cout << "Packet received: " << size << " bytes";
            std::cout << std::endl;
        }
    }
    return NULL;
}


int main() {
    //open datagram socket
    sock = socket(AF_INET, SOCK_DGRAM, 0);
    if(sock < 0) {
        perror("Could not open socket");
        return 1;
    }
    //bind socket to port
    struct sockaddr_in addr;
    addr.sin_family = AF_INET;
    addr.sin_port = htons(1337);
    addr.sin_addr.s_addr = 0;
    if(bind(sock, (struct sockaddr *) &addr, sizeof(addr)) < 0) {
        perror("Could not bind datagram socket");
        return 2;
    }
    //create the listener thread
    pthread_t t;
    if(pthread_create(&t, NULL, tfun, NULL) != 0) {
        perror("Could not thread");
        return 3;
    };
    //wait
    std::cin.get();
    //cancel the listener thread. pthread_cancel does not block.
    std::cout << "Cancelling thread" << std::endl;
    if(pthread_cancel(t) != 0) {
        perror("Could not cancel thread");
    }
    //join (blocks until the thread has actually cancelled).
    std::cout << "Joining thread" << std::endl;
    if(pthread_join(t, NULL) != 0) {
        perror("Could not join thread");
    } else {
        std::cout << "Join successful" << std::endl;
    }
    //close socket
    if(close(sock) != 0) {
        perror("Could not close socket");
    };
}

However, std::thread does not support cancel, nor does std::this_thread support setcancelstate (You'll find a reference here). It does, however, support native_handle, which returns the internally used pthread_t id. The obvious approach of just sending pthread_cancel() to the thread's native handle results in a segmentation fault, though:

#include <iostream>
#include <thread>
#include <cstdio>

#include <arpa/inet.h>
#include <unistd.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <pthread.h>
#include <net/if.h>
#include <ifaddrs.h>

int sock;

void tfun() {
    std::cout << "Thread running" << std::endl;
    while(true) {
        char buf[256];
        struct sockaddr_in addr;
        addr.sin_family = AF_INET;
        socklen_t addrlen = sizeof(addr);

        //perform the blocking recvfrom syscall
        int size = recvfrom(sock, (void *) buf, sizeof(buf), 0,
            (struct sockaddr *) &addr, &addrlen);

        if(size < 0) {
            perror("Could not receive packet");
            return;
        } else {
            //process the packet in the most complex ways
            //you could imagine.
            std::cout << "Packet received: " << size << " bytes";
            std::cout << std::endl;
        }
    }
    return;
}

int main() {
    //open datagram socket
    sock = socket(AF_INET, SOCK_DGRAM, 0);
    if(sock < 0) {
        perror("Could not open socket");
        return 1;
    }
    //bind socket to port
    struct sockaddr_in addr;
    addr.sin_family = AF_INET;
    addr.sin_port = htons(1337);
    addr.sin_addr.s_addr = 0;
    if(bind(sock, (struct sockaddr *) &addr, sizeof(addr)) < 0) {
        perror("Could not bind datagram socket");
        return 2;
    }
    //the listener thread
    std::thread *t = new std::thread(&tfun);
    //wait
    std::cin.get();
    //cancel the listener thread. pthread_cancel does not block.
    std::cout << "Cancelling thread" << std::endl;
    if(pthread_cancel(t->native_handle()) != 0) {
        perror("Could not cancel thread");
    }
    //join (blocks until the thread has actually cancelled).
    std::cout << "Joining thread" << std::endl;
    t->join();
    delete t;
    //close socket
    if(close(sock) != 0) {
        perror("Could not close socket");
    };
}

results in:

(gdb) run
Starting program: /tmp/test/test-dbg 
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7ffff6550700 (LWP 11329)]
Thread running

Cancelling thread
Joining thread

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff6550700 (LWP 11329)]
0x00007ffff6e67b45 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/libstdc++.so.6

Is there any way to cancel a std::thread while it's blocking in a syscall?

edit

I'm not asking for a cross-platform solution; a POSIX-conforming solution would suffice.

mic_e
  • 5,594
  • 4
  • 34
  • 49
  • 7
    I've always found the notion of cancelling a thread extremely philosophically questionable and opaque. What does it mean to "cancel" an execution flow? What sort of state will your program be in? It would be much saner to use non-blocking I/O, throw in an event file descriptor and an epoll loop, and set an event that makes the thread return. (In practice, I think thread cancellation in Posix is done by raising a signal within the thread, and nobody likes signals.) – Kerrek SB Sep 09 '12 at 16:22
  • AFAIK there is not a platform-independent portable way to cancel any old `std::thread`. – obataku Sep 09 '12 at 16:26
  • 1
    @Kerrek: While it's certainly true that nobody likes signals (I tried to solve the problem with these manually, and it ended horribly), the state of the thread after cancelling is very well-defined. Look at the pthread_cancel (3) manpage, and it will tell you that cancellation is only done during a defined set of function calls, and only while I allow it via setcancelstate. Could you please provide an example of non-blocking recvmsg() IO that does not eat up 100% CPU? – mic_e Sep 09 '12 at 16:27
  • 1
    @mic_e: At least in Linux, I've come to the conclusion that by far the best way to do anything at all is non-blocking sockets and epoll: You through a signalfd, some timerfds, inotify-fds and eventfds into the epoll set to handle all the usual async stuff. Network sockets go in there naturally, too. File descriptors will too, eventually, but only if you have long, expensive file operations. Most importantly, *other* epoll fds can go in the epoll set, and thus you can do almost all of your synchronisation in the kernel! – Kerrek SB Sep 09 '12 at 16:35
  • While `pthread_cancel` might be well-defined - I agree with @KerrekSB, in that threads should aim to be cooperative, not competitive. However, you may have a platform-specific problem: Linux NPTL (pthreads) use the EH (exception handling) runtime for cancellation. [This exception cannot be ignored, and must be at least rethrown in a C++ program](http://udrepper.livejournal.com/21541.html). – Brett Hale Sep 10 '12 at 14:38
  • I know this is an old thread, but `pthread_cancel` is fixed for `std::thread` for GCC 8. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917 – Jens Munk Apr 09 '18 at 22:14
  • @JensMunk: Thanks for the update! – mic_e Apr 10 '18 at 17:44

2 Answers2

5

I am going to suggest a workaround along the lines of well-known self-pipe trick for unblocking select(2) and sidestep the whole messy thread cancellation business.

Since you know the IP address and the port of the socket(7) your thread is blocking on, just sendto(2) some well-known sentinel packet to it from your main thread that would indicate that it's time to break out of the loop.

This way you don't have to subvert the std::thread abstraction and can stay reasonably portable.

Edit 0:

If you don't like workaround, call it a technique :)

Nikolai Fetissov
  • 82,306
  • 11
  • 110
  • 171
  • 1
    I've already thought about that solution, but then discarded it because (AFAIK) an attacker could send such a 'cancel' packet using a forged sender address. Well, I could set an internal cancel flag that I check for additionaly... – mic_e Sep 09 '12 at 16:37
  • @KerrekSB, yes `eventfd(2)` works, but is not portable and assumes event de-multiplexer like `select(2)`. @mic_e, since you are within same process, you can flip some global flag from main thread, and check that from your IO thread on return from `recvfrom(2)` and not even bother with packet content. – Nikolai Fetissov Sep 09 '12 at 16:43
  • @NikolaiNFetissov: True, but the tags say [tag:linux] and [tag:pthreads], so I wasn't too worried about portability :-) – Kerrek SB Sep 09 '12 at 16:50
  • Nikolai: well, it's fairly elegant: http://pastebin.com/4ZBQJ6tm, Kerrek: still, portability should always be preferred... while workarounds shouldn't. It's a dilemma. – mic_e Sep 09 '12 at 16:55
  • Well, depending on the scale of the project the full-blown non-blocking event dispatch ala libevent might be in order, but ... this worksTM :) – Nikolai Fetissov Sep 09 '12 at 17:06
3

You can interrupt the recvfrom by sending the thread a signal (e.g., SIGUSR1). On linux, you have to disable the libc autorestart behaviour (see recv() is not interrupted by a signal in multithreaded environment for details) for this to work.

Community
  • 1
  • 1
sim82
  • 88
  • 4