[#44036] [ruby-trunk - Feature #6242][Open] Ruby should support lists — "shugo (Shugo Maeda)" <redmine@...>
[#44084] [ruby-trunk - Bug #6246][Open] 1.9.3-p125 intermittent segfault — "jshow (Jodi Showers)" <jodi@...>
[#44156] [ruby-trunk - Feature #6265][Open] Remove 'useless' 'concatenation' syntax — "rosenfeld (Rodrigo Rosenfeld Rosas)" <rr.rosas@...>
Hi,
(2012/04/09 14:19), Yukihiro Matsumoto wrote:
[#44163] [ruby-trunk - Bug #6266][Open] encoding related exception with recent integrated psych — "jonforums (Jon Forums)" <redmine@...>
[#44233] [ruby-trunk - Bug #6274][Open] Float addition incorrect — "swanboy (Michael Swan)" <swanyboy4@...>
[#44303] [ruby-trunk - Feature #6284][Open] Add composition for procs — "pabloh (Pablo Herrero)" <pablodherrero@...>
[#44329] [ruby-trunk - Feature #6287][Open] nested method should only be visible by nesting/enclosing method — "botp (bot pena)" <botpena@...>
[#44349] [ruby-trunk - Feature #6293][Open] new queue / blocking queues — "tenderlovemaking (Aaron Patterson)" <aaron@...>
On Sat, Apr 14, 2012 at 10:58:12AM +0900, mame (Yusuke Endoh) wrote:
Hi,
On Mon, Apr 16, 2012 at 06:25:59PM +0900, SASADA Koichi wrote:
[#44372] Possible merge error of code in Issue 4651 on to Ruby 1.9.3-p125? — "Blythe,Aaron" <ABLYTHE@...>
tl;dr I believe I have uncovered a merge error to ruby 1.9.3-p125 from Issu=
[#44431] [Backport93 - Backport #6314][Open] Backport r35374 and r35375 — "drbrain (Eric Hodel)" <[email protected]>
[#44432] [ruby-trunk - Feature #6315][Open] handler to trace output of each line of code executed — "ankopainting (Anko Painting)" <anko.com+ruby@...>
[#44533] [ruby-trunk - Bug #6341][Open] SIGSEGV: Thread.new { fork { GC.start } }.join — "rudolf (r stu3)" <redmine@...>
Hello,
On Mon, Apr 23, 2012 at 11:17 PM, Yusuke Endoh <[email protected]> wrote:
Hello,
(4/24/12 6:55 AM), Yusuke Endoh wrote:
> kosaki (Motohiro KOSAKI) wrote:
[#44540] [ruby-trunk - Bug #6343][Open] Improved Fiber documentation — "andhapp (Anuj Dutta)" <anuj@...>
[#44612] [ruby-trunk - Feature #6354][Open] Remove escape (break/return/redo/next support) from class/module scope — "ko1 (Koichi Sasada)" <redmine@...>
[#44630] [ruby-trunk - Feature #6361][Open] Bitwise string operations — "MartinBosslet (Martin Bosslet)" <Martin.Bosslet@...>
On Fri, Apr 27, 2012 at 8:53 PM, MartinBosslet (Martin Bosslet)
On Saturday, April 28, 2012 at 8:52 AM, KOSAKI Motohiro wrote:
[#44636] [ruby-trunk - Bug #6364][Open] Segmentation fault happend when running test_cptr.rb — "raylinn@... (ray linn)" <raylinn@...>
[#44667] possible YAML bug in ruby 1.9.3p125? — Young Hyun <youngh@...>
YAML in ruby 1.9.3p125 seems to have a bug reading in YAML from older =
[#44686] [BUG] not a node 0x07 — ronald braswell <rpbraswell@...>
Running ruby 1.8.6 on Solaris 10.
2012/4/28 ronald braswell <[email protected]>:
I have heard reports of this on 1.9.x. Do you know if this problem has
[#44704] [ruby-trunk - Feature #6373][Open] public #self — "trans (Thomas Sawyer)" <transfire@...>
Issue #6373 has been updated by Marc-Andre Lafortune.
[#44743] [ruby-trunk - Feature #6375][Open] Python notation for literal Hash — "alexeymuranov (Alexey Muranov)" <redmine@...>
[#44748] [ruby-trunk - Feature #6376][Open] Feature lookup and checking if feature is loaded — "trans (Thomas Sawyer)" <transfire@...>
On Thu, May 3, 2012 at 6:02 AM, mame (Yusuke Endoh) <[email protected]> wrote:
[ruby-core:44213] Re: Questions about thread performance (with benchmark included)
Hi, (2012/03/28 21:51), Rodrigo Rosenfeld Rosas wrote: > Actually I have already read about this in some sites but I never found > an official documentation about threads behavior in MRI. I can say "It is true. Ruby 1.9 does (and 2.0 will) not run threads in parallel". > It seems that due to some global lock we can't get code to run > concurrently in CPU intensive applications. One global lock. We can run threads *concurrently*. Terminology: Concurrent: run multiple activities in logical (time sharing, etc). Parallel: run multiple activities simultaneously in physical. > I mean, threads are useless for those kind of applications. It seems > that threads in MRI are only useful for IO intensive applications or > some evented based applications. Basically, yes. > This is really a blocker issue for those willing to do intensive > calculations that will prevent them from using MRI and having to sort to > JRuby or other language for the job. > > I hope this will change for MRI at some point... Parallel threading have several problems, for example, debugging issue and single performance issue. Because of these issues I want to prepare another solution. > Specially for web servers this behavior leads to bad design from some > web frameworks that are optimized to be used with MRI. > > For example, Rails common deploy strategy is to use multiple processes > for dealing with concurrent requests, which will use much more memory > than would be required with a threaded environment. > > This is specially an issue if you're paying a VPS with prices varying by > available RAM. > > I think this strategy is the common one only for Ruby applications > (except from JRuby which doesn't have this limitation). > > This is totally weird and I guess most frameworks would have their > design changed to be optimized for threads usage if threaded code could > be run concurrently in CRuby. > > I don't think Ruby should ignore the fact that its current huge > popularity has came from the Rails framework and there are lots of > people willing to use it for web development, so it shouldn't be > considered as a second-class citizen. > > The most important limitation for CRuby nowadays is this lack of > concurrent threads code in my opinion. This is a blocker for the correct > deploy strategy. > > For example, you're currently not allowed to write long-polling > applications with CRuby and Rails because each long-polling request > would require a different process. > > Well, actually in this case you can use threads because this would fall > in the evented based category, but if you have some report action that > needs lots of computation it won't be able to compute the results faster > by using multiple cores. > > Are there any plans for changing this situation? Most servers will have > more than 6 cores and they won't be used in full capacity for CRuby > applications nowadays. No. -- // SASADA Koichi at atdot dot net