On 13 August 2012 16:47, Joe Buck <joe.b...@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.
