Bug 8960 – DMD tester: Unable to set thread priority

Status
RESOLVED
Resolution
FIXED
Severity
normal
Priority
P4
Component
druntime
Product
D
Version
D2
Platform
All
OS
All
Creation time
2012-11-04T21:37:00Z
Last change time
2015-02-18T03:38:00Z
Keywords
pull
Assigned to
nobody
Creator
andrej.mitrovich
See also
http://d.puremagic.com/issues/show_bug.cgi?id=9595

Comments

Comment #0 by andrej.mitrovich — 2012-11-04T21:37:40Z
This has recently been recurring randomly in the autotester. core.thread.ThreadException@src/core/thread.d(982): Unable to set thread priority I don't know whether it's an issue with the test machines or druntime, but it's becoming a problem since it's causing failed test runs for pull requests that are unrelated to threading.
Comment #1 by andrej.mitrovich — 2012-12-23T06:23:13Z
Looks like it's not happening anymore? Oh well..
Comment #2 by andrej.mitrovich — 2013-02-27T15:18:55Z
It still happens randomly in every other pull request, so I'll have to reopen.
Comment #3 by maxim — 2013-06-11T05:06:28Z
Reduced (compile with -unittest) ------------------------------------- import std.parallelism; import std.stdio; import core.thread; unittest { static void refFun(ref uint num) { num++; } uint x; // Test executeInNewThread(). auto ct = scopedTask!refFun(x); ct.executeInNewThread(Thread.PRIORITY_MAX); ct.yieldForce; assert(ct.args[0] == 1); } void main(){} --------------------------------- According to observations it can fail in getter or in setter of thread priority. It seems that return code from pthread setters/getters is 3 which is ESRCH, which in pthread context means non-existing thread. Following snippet from std.parallelism gives a clue: this(AbstractTask* task, int priority = int.max) { assert(task); // Dummy value, not used. instanceStartIndex = 0; this.isSingleTask = true; task.taskStatus = TaskStatus.inProgress; this.head = task; singleTaskThread = new Thread(&doSingleTask); singleTaskThread.start(); if(priority != int.max) { singleTaskThread.priority = priority; } } Thread may finish before setting priorities as it was started before applying them. It seems that thread ID is same in three cases 1) before getter 2) before setter 3) in gdb message informing that thread has finished. Originally I got approx 1-2 per 100 executions but after inserting debug outputs the failure percentage increased (as I suppose) because thread had more chances to terminate before applying priorities. Also, there were cases when gdb reported that thread has finished before priority setter started execution. Can someone who uses FreeBSD check this? https://github.com/mxfm/phobos/commit/50854c479e4d965271fbb91f9203d24ac81b6820 https://github.com/mxfm/druntime/commit/0d60b15efdaebae65ee9109ca3a90aaee177a341
Comment #4 by maxim — 2013-06-13T00:38:54Z
Comment #5 by maxim — 2013-06-13T00:39:50Z
*** Issue 9595 has been marked as a duplicate of this issue. ***
Comment #6 by code — 2013-12-05T07:29:26Z
Also fails on OSX.
Comment #7 by code — 2013-12-05T07:30:46Z
Comment #8 by github-bugzilla — 2014-09-28T23:12:01Z
Commits pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/62696b4d8aa1f919071d8d3726c06998b06dd787 fix Issue 8960 - Unable to set thread priority - Ignore error when get-/setting the priority of a terminated thread. https://github.com/D-Programming-Language/druntime/commit/b188057f1b9edd57cb956c5fdd86a7878a6529d9 Merge pull request #550 from MartinNowak/fix8960 fix Issue 8960 - Unable to set thread priority
Comment #9 by github-bugzilla — 2015-02-18T03:38:00Z