[#27380] [Bug #2553] Fix pthreads slowness by eliminating unnecessary sigprocmask calls — Dan Peterson <redmine@...>

Bug #2553: Fix pthreads slowness by eliminating unnecessary sigprocmask calls

21 messages 2010/01/03

[#27437] [Feature #2561] 1.8.7 Patch reduces time cost of Rational operations by 50%. — Kurt Stephens <redmine@...>

Feature #2561: 1.8.7 Patch reduces time cost of Rational operations by 50%.

9 messages 2010/01/06

[#27447] [Bug #2564] [patch] re-initialize timer_thread_{lock,cond} after fork — Aliaksey Kandratsenka <redmine@...>

Bug #2564: [patch] re-initialize timer_thread_{lock,cond} after fork

18 messages 2010/01/06

[#27635] [Bug #2619] Proposed method: Process.fork_supported? — Hongli Lai <redmine@...>

Bug #2619: Proposed method: Process.fork_supported?

45 messages 2010/01/20
[#27643] [Feature #2619] Proposed method: Process.fork_supported? — Luis Lavena <redmine@...> 2010/01/21

Issue #2619 has been updated by Luis Lavena.

[#27678] Re: [Feature #2619] Proposed method: Process.fork_supported? — Yukihiro Matsumoto <matz@...> 2010/01/22

Hi,

[#27684] Re: [Feature #2619] Proposed method: Process.fork_supported? — Charles Oliver Nutter <headius@...> 2010/01/22

On Thu, Jan 21, 2010 at 11:27 PM, Yukihiro Matsumoto <matz@ruby-lang.org> w=

[#27708] Re: [Feature #2619] Proposed method: Process.fork_supported? — Yukihiro Matsumoto <matz@...> 2010/01/22

Hi,

[#27646] Re: [Bug #2619] Proposed method: Process.fork_supported? — Tanaka Akira <akr@...> 2010/01/21

2010/1/21 Hongli Lai <redmine@ruby-lang.org>:

[#27652] Re: [Bug #2619] Proposed method: Process.fork_supported? — Hongli Lai <hongli@...99.net> 2010/01/21

On 1/21/10 5:20 AM, Tanaka Akira wrote:

[#27653] Re: [Bug #2619] Proposed method: Process.fork_supported? — Tanaka Akira <akr@...> 2010/01/21

2010/1/21 Hongli Lai <hongli@plan99.net>:

[#27662] Re: [Bug #2619] Proposed method: Process.fork_supported? — Vladimir Sizikov <vsizikov@...> 2010/01/21

On Thu, Jan 21, 2010 at 10:53 AM, Tanaka Akira <akr@fsij.org> wrote:

[#27698] [Bug #2629] ConditionVariable#wait(mutex, timeout) should return whether the condition was signalled, not the waited time — Hongli Lai <redmine@...>

Bug #2629: ConditionVariable#wait(mutex, timeout) should return whether the condition was signalled, not the waited time

8 messages 2010/01/22

[#27722] [Feature #2635] Unbundle rdoc — Yui NARUSE <redmine@...>

Feature #2635: Unbundle rdoc

14 messages 2010/01/23

[#27757] [Bug #2638] ruby-1.9.1-p37[68] build on aix5.3 with gcc-4.2 failed to run for me because it ignores where libgcc is located. — Joel Soete <redmine@...>

Bug #2638: ruby-1.9.1-p37[68] build on aix5.3 with gcc-4.2 failed to run for me because it ignores where libgcc is located.

10 messages 2010/01/24

[#27778] [Bug #2641] Seg fault running miniruby during ruby build on Haiku — Alexander von Gluck <redmine@...>

Bug #2641: Seg fault running miniruby during ruby build on Haiku

10 messages 2010/01/25

[#27791] [Bug #2644] memory over-allocation with regexp — Greg Hazel <redmine@...>

Bug #2644: memory over-allocation with regexp

12 messages 2010/01/25

[#27794] [Bug #2647] Lack of testing for String#split — Hugh Sasse <redmine@...>

Bug #2647: Lack of testing for String#split

14 messages 2010/01/25

[#27912] [Bug #2669] mkmf find_executable doesn't find .bat files — Roger Pack <redmine@...>

Bug #2669: mkmf find_executable doesn't find .bat files

11 messages 2010/01/27

[#27930] [Bug:trunk] some behavior changes of lib/csv.rb between 1.8 and 1.9 — Yusuke ENDOH <mame@...>

Hi jeg2, or anyone who knows the implementation of FasterCSV,

15 messages 2010/01/28
[#27931] Re: [Bug:trunk] some behavior changes of lib/csv.rb between 1.8 and 1.9 — James Edward Gray II <james@...> 2010/01/28

On Jan 28, 2010, at 10:51 AM, Yusuke ENDOH wrote:

[ruby-core:27590] Re: better GC?

From: Brian Mitchell <binary42@...>
Date: 2010-01-14 18:05:42 UTC
List: ruby-core #27590
2010/1/14 Gon=E7alo Silva <goncalossilva@gmail.com>:
> So, we're getting the worse of the two options. GC will still be slow and
> people will need to fix their ruby gems. I don't see how this is good for=
 us
> or Ruby itself.

The key is that there would be a correct way to write things that
could avoid most of the penalty, if I read that right. You'd pay a tax
for extensions that aren't using the new API. So they are slow, what's
new? The option here is to give us some future and the ability to
improve the software we do have control over.

Assuming we don't jump to the ideal GC approach in one big bang...
What we need to decide is what the most appropriate first steps are. I
think there is room to employ new APIs. Penalties are fair. If this
weren't the case, then someone might be complaining that their 286
running in real mode should be able to run a modern operating system
right now. We had to take a hit with that software compatibility and
even performance as protected modes were added.

Let's not freeze progress because something someone did might need
rework. For those who don't want the penalty, well, they can keep
using the current implementation as that's probably what they would be
stuck without these proposed efforts anyway.

Brian.

In This Thread