[#29911] [Bug #3231] Digest Does Not Build — Charlie Savage <redmine@...>

Bug #3231: Digest Does Not Build

19 messages 2010/05/01

[#29920] [Feature #3232] Loops (while/until) should return last statement value if any, like if/unless — Benoit Daloze <redmine@...>

Feature #3232: Loops (while/until) should return last statement value if any, like if/unless

9 messages 2010/05/01

[#29997] years in Time.utc — Xavier Noria <fxn@...>

Does anyone have a precise statement about the years supported by

13 messages 2010/05/04

[#30010] [Bug #3248] extension 'tk' is finding tclConfig.sh and tkConfig.sh incorrectly — Luis Lavena <redmine@...>

Bug #3248: extension 'tk' is finding tclConfig.sh and tkConfig.sh incorrectly

9 messages 2010/05/05

[#30226] [Bug #3288] Segmentation fault - activesupport-3.0.0.beta3/lib/active_support/callbacks.rb:88 — Szymon Jeż <redmine@...>

Bug #3288: Segmentation fault - activesupport-3.0.0.beta3/lib/active_support/callbacks.rb:88

10 messages 2010/05/13

[#30358] tk doesn't startup well in doze — Roger Pack <rogerdpack2@...>

Currently with 1.9.x and tk 8.5,the following occurs

12 messages 2010/05/22

[ruby-core:30256] Re: [Feature #3176] Thread#priority= should actually do something

From: KOSAKI Motohiro <kosaki.motohiro@...>
Date: 2010-05-15 16:50:45 UTC
List: ruby-core #30256
> Issue #3176 has been updated by Yusuke Endoh.
>
> Assigned to set to Koichi Sasada
> Target version set to 1.9.x
>
> Hi, Caleb
>
> Great.  glanced over your patch.  think the biggest change is how
> thread waits GVL. t is quite funny because ko1 recently does the
> same to fix another issue (thread starvation on many core environment).
> (The fix have not been committed yet.)
> I had concerned its performance cost, but if ko1 agrees with it, I
> also agree.
>
> However, ko1 seems to still dislike the priority support for some
> reason.  don't know the precise reason. e said he would answer to
> this ticket, so please wait for him.
>
>
> Anyway, thank you for your writing a patch.
>
> One comment for the patch: not-static functions (like pqueue_*) should
> prefix "rb_" to avoid conflict with symbols of other projects, even if
> they are just for internal.

Alternative patch is here. I mean we should use os's thread priority
interface if possible.

The test result of caleb's testcase is,

    ./ruby projects/thrprio/thrprio.rb
    315662770 209679 0.9986723818385312 true

Hmm...
Current MRI internal seems to have too many yield() and sleep(). Linux
setpriority()
give a thread to 1.25 times timeslice bonus per a nice. but this test  but now
t1 got about 1500 times bonus against t2. ;-)


diff --git a/thread_pthread.c b/thread_pthread.c
index e6295db..dd66c40 100644
--- a/thread_pthread.c
+++ b/thread_pthread.c
@@ -535,7 +535,23 @@ native_thread_join(pthread_t th)
 static void
 native_thread_apply_priority(rb_thread_t *th)
 {
-#if defined(_POSIX_PRIORITY_SCHEDULING) && (_POSIX_PRIORITY_SCHEDULING > 0)
+#ifdef linux
+    int priority = 0 - th->priority;
+
+    if (priority > 19)
+           priority = 19;
+
+    /*
+     * No privileged can't use <0 priority. But we don't need care it.
+     * Setpriority() naturally ignore such call.
+     */
+    if (priority < -20)
+           priority = -20;
+
+    /* Strangely, Linux's setpriority(PRIO_PROCESS) change per-thread
priority. */
+    setpriority(PRIO_PROCESS, 0, priority);
+    return;
+#elif defined(_POSIX_PRIORITY_SCHEDULING) && (_POSIX_PRIORITY_SCHEDULING > 0)
     struct sched_param sp;
     int policy;
     int priority = 0 - th->priority;

In This Thread