[boost] [thread] API for getting/setting thread name in Boost?

[Bob Summerwill]

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.

https://github.com/ethereum/libweb3core/pull/73
https://github.com/ethereum/libweb3core/pull/73/files

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);



Would I be right in assuming that this never happened?

http://boost.2283326.n4.nabble.com/Adding-an-option-to-set-the-name-of-a-boost-thread-td4638283.html


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.

http://stackoverflow.com/questions/10121560/stdthread-naming-your-thread


Cheers,
Bob Summerwill
--
b...@summerwill.net

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Vicente J. Botet Escriba]

I remember this thread

> Would I be right in assuming that this never happened?

Unfortunately not. Nobody provided a patch.

>
> http://boost.2283326.n4.nabble.com/Adding-an-option-to-set-the-name-of-a-boost-thread-td4638283.html
>
>
> 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
solution.

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.

>
> http://stackoverflow.com/questions/10121560/stdthread-naming-your-thread
>
>
> Cheers,
> Bob Summerwill

Best,
Vicente

[Bob Summerwill]

My apologies for the cut-and-paste here. I had "digest enabled".

Vicente >> I remember this thread
Vicente >> Unfortunately not. Nobody provided a patch.


OK - well maybe I need to put that on my backlog. It just one code-path
for Windows and another for POSIX. Just a few lines of code for each.

Vicente >> You can add a Feature request on Trac system or create an issue
on
Vicente >> Github, but I don't believe I will work on that if there is no
portable
Vicente >> solution.

So I couldn't find an active issue tracker on the repos in Github. I
tried to create a Trac issue, but it rejected my ticket for having external
links (yep, there are a lot). Maybe it will be nicer to me if I had a SVN
account. I do not. Is trac the primary issue-tracker?

[Vicente J. Botet Escriba]

Le 06/05/2016 à 21:05, Bob Summerwill a écrit :
> My apologies for the cut-and-paste here. I had "digest enabled".
>
> Vicente >> I remember this thread
> Vicente >> Unfortunately not. Nobody provided a patch.
>
>
> OK - well maybe I need to put that on my backlog. It just one code-path
> for Windows and another for POSIX. Just a few lines of code for each.

I don't know of a portable POSIX solution. Do you?

>
> Vicente >> You can add a Feature request on Trac system or create an issue
> on
> Vicente >> Github, but I don't believe I will work on that if there is no
> portable
> Vicente >> solution.
>
> So I couldn't find an active issue tracker on the repos in Github.

Oh, I believed there were one. I will request to the administrators to
see what can be done.

> I
> tried to create a Trac issue, but it rejected my ticket for having external
> links (yep, there are a lot).

Yes Trac don't support links :(.

> Maybe it will be nicer to me if I had a SVN
> account. I do not.

You don't need an svn account.

> Is trac the primary issue-tracker?
>

Yes. We want to move to github however.

Vicente

[Vicente J. Botet Escriba]

Le 08/05/2016 à 14:34, Vicente J. Botet Escriba a écrit :
> Le 06/05/2016 à 21:05, Bob Summerwill a écrit :
>> So I couldn't find an active issue tracker on the repos in Github.
> Oh, I believed there were one. I will request to the administrators to
> see what can be done.
>> I
>> tried to create a Trac issue, but it rejected my ticket for having
>> external
>> links (yep, there are a lot).
> Yes Trac don't support links :(.
>> Maybe it will be nicer to me if I had a SVN
>> account. I do not.
> You don't need an svn account.
>> Is trac the primary issue-tracker?
>>
> Yes. We want to move to github however.
>

You can create now an issue on github.

https://github.com/boostorg/thread/issues

Vicente

[Bob Summerwill]

My language wasn't quite precise enough!

I don't believe there is a single implementation which will work on all
POSIX-compliant systems, but it looks like we're close enough to de-facto
standardization that we can get something which will work on all the major
platforms.

It's essentially looking at:

http://stackoverflow.com/questions/2369738/can-i-set-the-name-of-a-thread-in-pthreads-linux/7989973#7989973

Which gives you code something like this:

https://github.com/ethereum/libweb3core/blob/develop/libdevcore/Log.cpp#L176

And the Windows equivalent:

http://stackoverflow.com/questions/905876/how-to-set-name-to-a-win32-thread

Thanks, Vincente for setting up the Github issue tracker, and for your
reply. I will log an issue there now.

Cheers,
Bob

[Bob Summerwill]

Issue logged as https://github.com/boostorg/thread/issues/84. Thanks!

[Vicente J. Botet Escriba]

Le 10/05/2016 à 01:57, Bob Summerwill a écrit :
> Issue logged as https://github.com/boostorg/thread/issues/84. Thanks!

Hi Bob,

What I have in mind was to use the boost::thread_attributes, but we are
unable to do it in OSX as the set name in OSX sets the name of the
current thread :(
After some thought I believe we could do it by using a trampoline that
will do the setting before calling the user main thread function, but
this is more complex and needs to store the name in the thread_data context.

IIUC, what you are proposing and the single thing that could be done in
an almost portable way and easily is to define two non-member functions
to set and get the thread name on namespace this_thread or any other. Is
this what you are proposing? If this is the case, this functionality can
be developed completely independently of Boost.Thread, isn't' it?

Best,
Vicente