Closed
Bug 1298451
Opened 9 years ago
Closed 9 years ago
js/src/threading/posix/Thread.cpp:177:54: error: 'pthread_get_name_np' was not declared in this scope
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
FIXED
mozilla51
Tracking | Status | |
---|---|---|
firefox51 | --- | fixed |
People
(Reporter: jbeich, Unassigned)
References
Details
(Keywords: regression)
Attachments
(1 file)
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
Keywords: regression
Comment 1•9 years ago
|
||
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 hidden (mozreview-request) |
Comment 3•9 years ago
|
||
mozreview-review |
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?
Attachment #8785568 -
Flags: review?(sphink) → review+
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
Keywords: checkin-needed
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
Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/4af226179028
Unbreak build on DragonFly, FreeBSD, OpenBSD. r=sfink
Keywords: checkin-needed
Comment 7•9 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
You need to log in
before you can comment on or make changes to this bug.
Description
•