Patchwork [v3] improve exception text when threads not enabled

login
register
mail settings
Submitter Jonathan Wakely
Date Aug. 12, 2012, 7:02 p.m.
Message ID <CAH6eHdRf6Ob0ycuoeBS_Ufpp6006iNMh9VZtMizisk+M24tqhQ@mail.gmail.com>
Download mbox | patch
Permalink /patch/176789/
State New
Headers show

Comments

Jonathan Wakely - Aug. 12, 2012, 7:02 p.m.
This improves the fairly uninformative "Operation not supported"
message given when std::thread is used without linking to libpthread.

Now you get:

terminate called after throwing an instance of 'std::system_error'
  what():  Enable multithreading to use std::thread: Operation not permitted
Aborted

        PR libstdc++/52681
        * src/c++11/thread.cc (thread::_M_start_thread): Improve error text
        when threads are not enabled.

Tested x86_64-linux, with exceptions enabled and disabled. Committed to trunk.
commit d79ac9a14880d5f20fd62c72d87c4f3405727350
Author: redi <redi@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Sun Aug 12 18:57:53 2012 +0000

    	PR libstdc++/52681
    	* src/c++11/thread.cc (thread::_M_start_thread): Improve error text
    	when threads are not enabled.
    
    git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@190330 138bc75d-0d04-0410-961f-82ee72b054a4
Joe Buck - Aug. 13, 2012, 3:47 p.m.
On Sun, Aug 12, 2012 at 08:02:30PM +0100, Jonathan Wakely wrote:
> This improves the fairly uninformative "Operation not supported"
> message given when std::thread is used without linking to libpthread.
> 
> Now you get:
> 
> terminate called after throwing an instance of 'std::system_error'
>   what():  Enable multithreading to use std::thread: Operation not permitted
> Aborted

The new message still seems deficient.  The issue is that the executable
does not contain any thread support; "not permitted" usually suggests a
permission violation (like trying to write a read-only file).  Perhaps "no
thread support found" should be used instead of "Operation not permitted".
Jonathan Wakely - Aug. 13, 2012, 5:49 p.m.
On 13 August 2012 16:47, Joe Buck <Joe.Buck@synopsys.com> wrote:
> On Sun, Aug 12, 2012 at 08:02:30PM +0100, Jonathan Wakely wrote:
>> This improves the fairly uninformative "Operation not supported"
>> message given when std::thread is used without linking to libpthread.
>>
>> Now you get:
>>
>> terminate called after throwing an instance of 'std::system_error'
>>   what():  Enable multithreading to use std::thread: Operation not permitted
>> Aborted
>
> The new message still seems deficient.  The issue is that the executable
> does not contain any thread support; "not permitted" usually suggests a
> permission violation (like trying to write a read-only file).  Perhaps "no
> thread support found" should be used instead of "Operation not permitted".

"Operation not permitted" is what it has always printed, it's the
strerror text corresponding to EPERM, which is the error code we throw
in the std::system_error exception when thread support is not present.

std::system_error::what() is required to return a string
"incorporating the arguments supplied in the constructor" so it should
print a string corresponding to some standard error number. In
libstdc++ those strings are the same ones as returned by strerror.

std::thread is documented as throwing a std::system_error exception
with the error code EAGAIN if a thread couldn't be created, but
"Resource temporarily unavailable" would be misleading since no matter
how many times you try no thread can ever be created.  Instead we make
it throw a std::system_error with EPERM.

I suppose EOPNOTSUPP might be better, if it's supported everywhere.
EPERM has the advantage of being a documented error for
pthread_create.

In short, if you want to replace the "Operation not found" string you
ned to pick an errno value.  The "Enable multithreading to use
std::thread" part is free text that can be replaced or extended, but I
didn't want the message to be too long.
Jonathan Wakely - Aug. 13, 2012, 6:09 p.m.
On 13 August 2012 18:49, Jonathan Wakely wrote:
> I suppose EOPNOTSUPP might be better, if it's supported everywhere.
> EPERM has the advantage of being a documented error for
> pthread_create.

We do define std::errc::operation_not_supported unconditionally on
most platforms, but not mingw or djgpp.  They don't necessarily
support std::errc::operation_not_permitted either, and so far noone
has made std::thread work on those targets anyway, so that's not a
showstopper.

e.g.

terminate called after throwing an instance of 'std::system_error'
  what():  Enable multithreading to use std::thread: Operation not supported
Aborted

Patch

diff --git a/libstdc++-v3/src/c++11/thread.cc b/libstdc++-v3/src/c++11/thread.cc
index ff034b1..5c10832 100644
--- a/libstdc++-v3/src/c++11/thread.cc
+++ b/libstdc++-v3/src/c++11/thread.cc
@@ -115,7 +115,12 @@  _GLIBCXX_BEGIN_NAMESPACE_VERSION
   thread::_M_start_thread(__shared_base_type __b)
   {
     if (!__gthread_active_p())
+#if __EXCEPTIONS
+      throw system_error(make_error_code(errc::operation_not_permitted),
+			 "Enable multithreading to use std::thread");
+#else
       __throw_system_error(int(errc::operation_not_permitted));
+#endif
 
     __b->_M_this_ptr = __b;
     int __e = __gthread_create(&_M_id._M_thread,