summaryrefslogtreecommitdiffstats
path: root/tools/build/Makefile.am
diff options
context:
space:
mode:
authorJoel Sherrill <joel.sherrill@OARcorp.com>1999-07-28 18:03:20 +0000
committerJoel Sherrill <joel.sherrill@OARcorp.com>1999-07-28 18:03:20 +0000
commitf94e76ba023ad531db5a27c6f974fab5cb5f320b (patch)
treeae1920dcc37d4ae66c39348c054e292e542f9c75 /tools/build/Makefile.am
parentf28dfb368c6cfd3c683564e3ce9f2779433efa21 (diff)
downloadrtems-f94e76ba023ad531db5a27c6f974fab5cb5f320b.tar.bz2
Fix after this report from Peter Pointner <pr@schenk.isar.de>:
Problem: a posix thread which is created by pthread_attr_init(&tattr); pthread_attr_setinheritsched(&tattr, PTHREAD_EXPLICIT_SCHED); pthread_attr_setschedpolicy(&tattr, SCHED_RR); pthread_create(&th, &tattr, func, arg); has a first timeslice of 2^32 ticks (changing a running thread to SCHED_RR id ok). I use RTEMS-4.0.0. I am not sure if the problem exists in the current CVS head revision. If it's not fixed, the patch at the end should do it. Peter --- pthreadcreate.c.orig Wed Jul 28 14:45:58 1999 +++ pthreadcreate.c Wed Jul 28 15:06:09 1999 @@ -199,6 +199,10 @@ api->schedpolicy = schedpolicy; api->schedparam = schedparam; + if ( schedpolicy == SCHED_RR ) { + the_thread->cpu_time_budget = _Thread_Ticks_per_timeslice; + } + /* * This insures we evaluate the process-wide signals pending when we * first run.
Diffstat (limited to '')
0 files changed, 0 insertions, 0 deletions