[#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:30310] Re: [Feature #3176] Thread#priority= should actually do something

From: KOSAKI Motohiro <kosaki.motohiro@...>
Date: 2010-05-19 10:16:39 UTC
List: ruby-core #30310
Hi

> Kosaki, I have tried using setpriority on linux to get the OS to handle priorities, but it failed
> in the same way that pthread_setschedparam did; the test script would never finish and
> wouldn't even respond to ^C. I have no idea why this is failing so badly. (Maybe a bug in
> linux?? More likely a bug in my understanding.)

Which test case do you use?  I'll investigate the issue.


> In any case, another problem with this approach is that you won't readily be able to set
> a thread to higher priority than the main thread. Altho there may be ways around this,
> they come with their own issues. For instance, if a ruby process is started at the lowest
> possible priority (highest nice level) it won't be ossible to have threads within that
> process be a different priority at all. On reflection, it seems better for ruby to manage its
> own thread priority queue (at least on linux) and have a guaranteed level of support for
> priorities and fixed number of available priorities.

JVM have the same limitation. Then, I guess JRuby too.

http://java.sun.com/j2se/1.5.0/docs/guide/vm/thread-priorities.html#150

So, I think we can accept the limitation too.

In This Thread