1298451 - js/src/threading/posix/Thread.cpp:177:54: error: 'pthread_get_name_np' was not declared in this scope

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Jan Beich]

pthread_get_name_np() doesn't exist. Getting a thread name may require iterating through a list of |struct kinfo_proc| for a given getpid(). Do we even need to call into OS if it was set by Gecko?

js/src/threading/posix/Thread.cpp:177:3: error: use of undeclared identifier
      'pthread_get_name_np'
  pthread_get_name_np(pthread_self(), nameBuffer, len);
  ^
1 error generated.

https://lists.freebsd.org/pipermail/freebsd-hackers/2016-March/049294.html

Comment 1

[Steve Fink [:sfink] [:s:]]

We are attempting to make SpiderMonkey stop using NSPR. Gecko currently sets its thread name via NSPR, which uses pthread_setname_np if available, otherwise it stores it in TLS. Given that this code is for the purpose of eliminating NSPR, it unfortunately can't read it out of NSPR's TLS. (We have the same problem on Windows, though there's some other stuff going on there too.) See bug 1297215 for the Windows equivalent of this bug.

Having this API work is really not critical. If do not have pthread_getname_np, pthread_get_name_np, nor prctl(PR_GET_NAME), then I would recommend returning an empty string as we currently do on Windows.

In the future, we may change the callers of the NSPR stuff to also call the js/src/threading stuff, at which time we'd add our own (redundant) TLS store for the name. But for now, it's just not that important. (Currently, the only user is for naming threads in TraceLogger trace files.)

Comment 2

[Jan Beich]

Attachment: Bug 1298451 - Unbreak build on DragonFly, FreeBSD, OpenBSD.

Review commit: https://reviewboard.mozilla.org/r/74738/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/74738/

Comment 3

[Steve Fink [:sfink] [:s:]]

Comment on attachment 8785568 [details]
Bug 1298451 - Unbreak build on DragonFly, FreeBSD, OpenBSD.

https://reviewboard.mozilla.org/r/74738/#review72958

This is ok to land whatever your answer is, but I'm curious -- do you know that pthread_get_name_np is unavailable on all 3 of those OSes, or just on FreeBSD?

Comment 4

[Jan Beich]

I think, neither |void pthread_get_name_np(pthread_t, char *, size_t)| (as used by Firefox, Xapiand, grantila/q) nor |void pthread_get_name_np(pthread_t, char *)| (as used by libqi) nor even |char *pthread_get_name_np(pthread_t, size_t)| (as used by Xapiand) exists anywhere, not just on those 3 BSDs. PTL1 (not updated since 1997-07-09) has |char *pthread_get_name_np(pthread_t)| and RTAI has (static?) |int pthread_get_name_np(void *, unsigned long *)|. Those aren't supported by Firefox even as Tier3.

https://encrypted.google.com/search?q=%22pthread_get_name_np%22
https://github.com/search?q=pthread_get_name_np&type=Code

Comment 5

[Jan Beich]

OpenBSD and FreeBSD buildbot logs for comment 0 just in case:
http://buildbot.rhaalovely.net/builders/mozilla-central-amd64/builds/1834/steps/build/logs/stdio
http://buildbot.rhaalovely.net/builders/mozilla-central-freebsd-amd64/builds/943/steps/build/logs/stdio

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4af226179028
Unbreak build on DragonFly, FreeBSD, OpenBSD. r=sfink

Comment 7

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/4af226179028