Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #79975

std::thread does not follow RAII principles

Show all headers | View raw

I have noticed a rather odd, and somewhat annoying, design decision in
std::thread, which breaks RAII design.

Normally when you use a C++ class from the standard library which allocates
some resource, the class in question will make sure to properly freeing
that resource when the object is destroyed, which is par for the course in
good RAII design.

For example, rather obviously, if you create an object of type std::vector,
it will delete its allocated memory (and destroy the elements) when it's
itself destroyed.

A more noteworthy example of something that allocates a resource other than
memory is std::ofstream: When it's destroyed, if it has a file open, it will
properly close the file.

This adds safety because it minimizes the risk of mistakes, especially since
functions may be exited at surprising places thanks to exceptions. Like:

void foo()
{
    std::ofstream os("somefile");

    doSomething(); // this might throw!

    // ...
}

No matter how that function is exited, even if an exception is thrown,
that std::ofstream object will close the file so that the file handle isn't
leaked.

But now we come to std::thread. Suppose you have something like:

void foo()
{
    std::thread t(someFunction);

    doSomething();

    signalTheThreadToStop();
    t.join();
}

The problem with this is that if doSomething() throws an exception, the
program will crash. It doesn't even matter that you may be prepared for
the exception, like:

try { foo(); }
catch(...) { std::cout << "Exception thrown!\n"; }

the program will still crash, because std::thread does not like being
destroyed without being joined or detached, so it just terminates if that's
the case.

This is quite inconvenient, and as far as I know the standard library doesn't
really offer any utility to make disposing of the thread properly more
automatic. You'll have to write your own "thread handler" that will terminate
the thread properly when the thread object is destroyed, so that the
program won't crash if the function is exited unexpectedly.

This feels very counter to RAII principles, where objects should take care
of the resources they have allocated, rather than demanding the calling code
to manually do so.

Back to comp.lang.c++ | Previous | Next — Next in thread | Find similar | Unroll thread

Thread

std::thread does not follow RAII principles Juha Nieminen <nospam@thanks.invalid> - 2021-05-26 11:51 +0000
  Re: std::thread does not follow RAII principles Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-26 14:04 +0200
    Re: std::thread does not follow RAII principles MrSpook__u_8@_4fk8arybb76.eu - 2021-05-26 15:25 +0000
      Re: std::thread does not follow RAII principles Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-26 17:50 +0200
  Re: std::thread does not follow RAII principles Paavo Helde <myfirstname@osa.pri.ee> - 2021-05-26 17:35 +0300
    Re: std::thread does not follow RAII principles Manfred <noname@add.invalid> - 2021-05-26 17:44 +0200
    Re: std::thread does not follow RAII principles Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-26 17:52 +0200
      Re: std::thread does not follow RAII principles Paavo Helde <myfirstname@osa.pri.ee> - 2021-05-26 21:41 +0300
  Re: std::thread does not follow RAII principles scott@slp53.sl.home (Scott Lurndal) - 2021-05-26 15:20 +0000
    Re: std::thread does not follow RAII principles Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-26 17:54 +0200
      Re: std::thread does not follow RAII principles MrSpook_c7o6A5w1@9wp2.net - 2021-05-26 16:28 +0000
        Re: std::thread does not follow RAII principles Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-26 19:04 +0200
  Re: std::thread does not follow RAII principles MrSpook_0crgrbi6@q0jfxa33c.biz - 2021-05-26 15:24 +0000
    Re: std::thread does not follow RAII principles Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-26 18:02 +0200

csiph-web