CODEWITHSUNDEEP
c++linuxmultithreadingio
CodeMonkey
CodeMonkey

Reputation: 3668

Terminating blocking IO in Linux C++

I am doing serial IO on linux in c++ using multi-threading. Currently I am using a blocking read. That leaves me with no way stop the thread cought in the blocking read() except to forcefully terminate or interrupt the thread or use something like pthread cancellation. Now all over the net i see people scream at people suggesting they need to terminate there threads from a blocking IO. Usually its concerning memory leaks. Is there some magic memory leak that can appear out of a thread interruption as long as you clean up properly? 

try
{
    while(true)
    {
        blocking_read(fd,buffer,512);
    }
}catch(interrupt_exception)
{

}
//clean up, close fd, release heap memory, usual stuff

Or is my only alternative something like the below or implement a higher level protocol ensuring the blocking read receives a sign off input enabling it to shut itself down.

try
{
    while(running)
    {
        nonblocking_read(fd,buffer,512);

        if(cancel)
            running = false; //break return etc
    }
}

//clean up, close fd, release heap memory, usual stuff

So again, do there happen some magic memory leak in read() if you interrupt the thread causing it to throw a exception.

Or should i simply not care and let the destructor kill the thread(i assume thread terminates when you delete your object holding the thread)? and do clean up there? like

class MyClass{
    int fd;    
    Thread* myThread;
    ~MyClass(){
        delete myThread;
        close(fd);
    }
};

Thanks for any help!

Upvotes: 4

Views: 7179

Answers (3)

Tanner Sansbury
Tanner Sansbury

Reputation: 51941

read() should not leak memory. With both blocking and nonblocking reads, the application code is still responsible for the management of the memory provided as the buf argument. Interrupting read() via a signal will not throw an exception, so if use signals, you will need to check the result and errno.

  • If read() is interrupted by a signal before reading data, -1 will be returned with errno set to EINTR.
  • If read() is interrupted by a signal after reading some data, POSIX allows for either -1 to be returned with errno set to EINTR, or for read() to return the number of bytes already read.

If you use pthread_cancel() then an exception will be thrown. With this approach, you have the following options:

  • Perform cleanup by registering cleanup functions with pthread_cleanup_push().
  • Allocate dynamic memory, storing into thread specific storage via pthread_setspecific().
  • Manage the memory via an auto_ptr/unique_ptr.
  • Catch the abi::__forced_unwind exception, perform cleanup, and rethrow.

In general, consider avoiding thread cancellation. When possible, it is better, and more manageable, to have a shared flag that is used to break out of the loop. This allows the thread to perform any necessary cleanup, and prevents your implementation from being dependent on your threading library's implementation and any of its quirks.

For your case, where you are using a blocking read, consider polling the fd to see if data is available via select() with a timeout, and only call read() if the fd has data. This allows you to periodically check if the thread flag is set to no longer run, and prevents you from needing to deal with signals to interrupt the thread from read(), as read() should no longer block waiting on data.

Also, the behavior that occurs when deleting a thread object is dependent on the thread library. For example, deleting a pthread_t or boost::thread has no effect on the associated thread's execution.

Upvotes: 6

Damon
Damon

Reputation: 70186

I would really just send a signal to that thread, that's what signals are for. Set your global running to false in your handler, and have a while(running) loop like in your second snippet, and that's it.

read doesn't leak, it reads into a buffer that you have already allocated and that you know about. It either succeeds or fails (or blocks, but the signal will unblock it). If it does succeed, see what you can make of the data (it might still be partial read or corrupt or whatever), otherwise repeat until running is false.

Then clean up, free what you've allocated, and gracefully exit the thread (... or do whatever you want).

If I'm not mistaken the rather complicated "before and after receiving some data" situation about restarting syscalls doesn't arise at all when installing a handler without providing SA_RESTART, either.
But even so, if does arise, who cares -- in the end, the syscall can only either fail or succeed, and read can always return partial data even in absence of a signal, so you must always be prepared for that anyway. Thus, you are really only interested in whether you've collected enough data alltogether to make something useful of it, or whether the running flag has "magically" become false for some reason (that reason would be your signal handler).

Upvotes: 0

mythagel
mythagel

Reputation: 1839

pthread_cancel will not directly cause magic memory leaks. If your thread is expecting to be stopped at the well defined cancellation points (see the pthread_cancel man page for more details) then it is possible to design with this in mind.

The following test program shows no errors with valgrind, however, note that it is not portable to rely on an exception being generated when the thread is cancelled (see Cancellation and C++ Exceptions ) for the glibc implementation.

-nick

#include <cstdio>
#include <pthread.h>
#include <unistd.h>

void* thread_func(void*)
{
    try
    {
        char buf[2048];
        read(1, buf, 2048);
    }
    catch(...)
    {
        fprintf(stderr, "thread %lu cancelled\n", pthread_self());
        throw;
    }
    return NULL;
}

int main()
{
    pthread_t thread;
    int res =  pthread_create(&thread, NULL, thread_func, NULL);
    sleep(1);
    pthread_cancel(thread);
    void* tres;
    pthread_join(thread, &tres);
    return 0;
}

Upvotes: 2

Related Questions