Subject: Re: [boost] [thread] API for getting/setting thread name in Boost?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2016-05-04 17:02:37
Le 04/05/2016 19:25, Bob Summerwill a écrit :
> I've also been working with an external developer which is getting Ethereum
> C++ working on Alpine Linux, as a statically linked executable using musl,
> rather than glibc.
> One rather confusing element was related to setting and getting thread
> names, which is the process of working through this issue, I find appears
> not to have made its way into either Boost or the C++11 standard library,
> though it must be a very common cross-platform use-case.
> I've just added this comment-block, while fixing the issue:
> /// Set the current thread's log name.
> /// It appears that there is not currently any cross-platform way of setting
> /// thread names either in Boost or in the C++11 runtime libraries. What is
> /// more, the API for 'pthread_setname_np' is not even consistent across
> /// platforms which implement it.
> /// A proposal to add such functionality on the Boost mailing list, which
> /// I assume never happened, but which I should follow-up and ask about.
> /// http://boost.2283326.n4.nabble.com/Adding-an-option-to-set-the-name-of-a-boost-thread-td4638283.html
> /// man page for 'pthread_setname_np', including this crucial snippet of
> /// information ... "These functions are nonstandard GNU extensions."
> /// http://man7.org/linux/man-pages/man3/pthread_setname_np.3.html
> /// Stack Overflow "Can I set the name of a thread in pthreads / linux?"
> /// which includes useful information on the minor API differences between
> /// Linux, BSD and OS X.
> /// http://stackoverflow.com/questions/2369738/can-i-set-the-name-of-a-thread-in-pthreads-linux/7989973#7989973
> /// musl mailng list posting "pthread set name on MIPs" which includes the
> /// information that musl doesn't currently implement 'pthread_setname_np'
> /// https://marc.info/?l=musl&m=146171729013062&w=1
> void setThreadName(std::string const& _n);
I remember this thread
> Would I be right in assuming that this never happened?
Unfortunately not. Nobody provided a patch.
> If not, where can I log an issue to request that we revisit that? From
> what I can see, everybody is likely just cut-and-pasting much the same code
> for this functionality.
You can add a Feature request on Trac system or create an issue on
Github, but I don't believe I will work on that if there is no portable
If people believe this is a must I'll suggest them to write something
around (as a free function) and propose it to Boost as a mini-library
them can maintain. They have access to the native_handle and they can do
whatever they which with. If the re is no solution that can be applied
non-intrusively, I could consider to do something.
> Bob Summerwill
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk