From: Bill Kelly <billk@...>
Date: 2005-09-09T01:02:27+09:00
Subject: Re: [SOLUTION] MUD Client (#45)

From: "James Edward Gray II" <james@grayproductions.net>
> On Sep 7, 2005, at 10:33 PM, Morgan wrote:
> 
> > From my understanding (and a little testing), if you
> > have one thread pushing items onto an array, and
> > another thread using shift to pull them off (and ONLY
> > one thread doing each), you'll still get all your data in
> > proper order without having Thread.critical calls slowing
> > down your application.
> 
> It wouldn't surprise me at all if you're right, but you're basically  
> counting on Ruby internals here and I have a hard time seeing that as  
> a good idea.  What if the scripting interface launches a Thread to  
> scan the Queue for whatever reason?  Your assumptions have now been  
> violated and who knows what's going to happen.  The user made that  
> choice, so you were never consulted.

Also, what about when Ruby switches to a bytecode-based VM?
The granularity between context switches may change a lot.

Additionally, in the "Premature optimization is the root of
all evil" vein... 

$ time ruby -e '1_000_000.times { Thread.critical = true; Thread.critical = false }'

real    0m1.791s
user    0m0.030s
sys     0m0.000s

Less than two seconds on an old 1.3GHz Athlon system.  So it
seems fair to question the perception that Thread.critical
results in application slow-down.

Especially given:

$ time ruby -e 'class Foo; class << self; attr_accessor :spleen; end; end; \
1_000_000.times { Foo.spleen = true;  Foo.spleen = false }'

real    0m2.143s
user    0m0.010s
sys     0m0.010s

It appears Thread.critical is even faster than calling a
"normal" ruby accessor method.


Regards,

Bill