Heya Folks-
This is mainly for Zed and Mentalguy. I have been playing with the
new release of rubygems 0.9.0.8 and I have a major problem with the
requirement that fastthread needs to be required before thread. Just
requiring rubygems and then requiring fastthread right after that
will throw the error:
ez _blog $ ruby
require ''rubygems''
require ''fastthread''
__END__
/usr//lib/ruby/gems/1.8/gems/fastthread-0.5.3.1/lib/
fastthread.bundle: fastthread must be required before thread
(RuntimeError)
from /usr//lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:
32:in `require''
from -:2
ez _blog $ ruby -v
ruby 1.8.5 (2006-08-25) [i686-darwin8.7.1]
ez _blog $ gem -v
0.9.0.8
I have been requiring fastthread in Merb but now that mongrel uses
it I want to remove my requires for it from merb. But right now with
the new version of rubygems I can''t use fastthread installed as a gem
at all.
Is the solution to this just to install fastthread via setup.rb
instead of gems so we can require it first? Does fastthread really
have to be required first? Can this be changed?
Another area where I run into this issue is with rake. rake requires
thread when you invoke it form the command line before you get a
chance to require fastthread first. So you get the fastthread load
error.
Whats the best solution to this? Can fastthread be made to be ok if
it loads after thread? Fastthread is great and has really improved
the mem profile for me in a bunch of installs. But with this new
version of rubygems there doesn''t seem to be a way to use fastthread
at all if it is installed as a gem.
Here is the same test run with the current 0.9 version of rubygems:
ey00-s00089 ~ # ruby
require ''rubygems''
require ''fastthread''
__END__
ey00-s00089 ~ # ruby -v
ruby 1.8.5 (2006-08-25) [x86_64-linux]
ey00-s00089 ~ # gem -v
0.9.0
It works fine here. But I suspect this will start affecting more and
more folks as they upgrade to rubygems latest.
Thoughts?
Cheer-s
-- Ezra Zygmuntowicz
-- Lead Rails Evangelist
-- ez at engineyard.com
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)
On 12/26/06, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:> Heya Folks- > > This is mainly for Zed and Mentalguy. I have been playing with the > new release of rubygems 0.9.0.8 and I have a major problem with the > requirement that fastthread needs to be required before thread. Just > requiring rubygems and then requiring fastthread right after that > will throw the error: >Oh boy, I guess that deserve a post at rubygems mailing list (rubygems-developers at rubyforge.org)> ez _blog $ ruby > require ''rubygems'' > require ''fastthread'' > __END__ > /usr//lib/ruby/gems/1.8/gems/fastthread-0.5.3.1/lib/ > fastthread.bundle: fastthread must be required before thread > (RuntimeError) > from /usr//lib/ruby/site_ruby/1.8/rubygems/custom_require.rb: > 32:in `require'' > from -:2 > ez _blog $ ruby -v > ruby 1.8.5 (2006-08-25) [i686-darwin8.7.1] > ez _blog $ gem -v > 0.9.0.8 >FastThread "patches" thread library, its required that some things get defined by fastthread prior thread do his thing... (that was mental comment on this issue). I guess rubygems folks added thread part of rubygems now... something that isn''t good at all (why I require thread if my application I don''t use it?, just to say something).> I have been requiring fastthread in Merb but now that mongrel uses > it I want to remove my requires for it from merb. But right now with > the new version of rubygems I can''t use fastthread installed as a gem > at all. >I''ve been using RUBYOPT=rubygems so guess will suffer from the same illness.> Is the solution to this just to install fastthread via setup.rb > instead of gems so we can require it first? Does fastthread really > have to be required first? Can this be changed? >The setup.rb way is one possibility, the other is ask the rubygems teams to check their code.> Another area where I run into this issue is with rake. rake requires > thread when you invoke it form the command line before you get a > chance to require fastthread first. So you get the fastthread load > error. >Er... you''re using fastthread in rake? Could I ask what for? I suppose rake isn''t for long running tasks... The other workaround will be hack lib/ruby/1.8/thread.rb and require fastthread there.> Whats the best solution to this? Can fastthread be made to be ok if > it loads after thread? Fastthread is great and has really improved > the mem profile for me in a bunch of installs. But with this new > version of rubygems there doesn''t seem to be a way to use fastthread > at all if it is installed as a gem. > > Here is the same test run with the current 0.9 version of rubygems: > > ey00-s00089 ~ # ruby > require ''rubygems'' > require ''fastthread'' > __END__ > ey00-s00089 ~ # ruby -v > ruby 1.8.5 (2006-08-25) [x86_64-linux] > ey00-s00089 ~ # gem -v > 0.9.0 > > > It works fine here. But I suspect this will start affecting more and > more folks as they upgrade to rubygems latest. > > Thoughts? > > Cheer-s > > -- Ezra Zygmuntowicz > -- Lead Rails Evangelist > -- ez at engineyard.com > -- Engine Yard, Serious Rails Hosting > -- (866) 518-YARD (9273) > > > > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users >-- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi
On Tue, 2006-12-26 at 19:43 -0300, Luis Lavena wrote:> I guess rubygems folks added thread part of rubygems now... something > that isn''t good at all (why I require thread if my application I don''t > use it?, just to say something).I don''t know... it seems reasonable if they need to do something in a threadsafe manner. Even e.g. Singleton needs synchronization, though it doesn''t currently use Mutex to do it (IMO it _should_, fastthread weirdness aside). I''m not really sure what the best resolution here is. fastthread is ultimately intended to become a patch to Ruby core, of course. But that can''t happen immediately, especially as even with the patch in hand I would still need to sell the ruby-core folks on it... -mental -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20061227/4c2bf699/attachment.bin
On 12/27/06, MenTaLguY <mental at rydia.net> wrote:> On Tue, 2006-12-26 at 19:43 -0300, Luis Lavena wrote: > > I guess rubygems folks added thread part of rubygems now... something > > that isn''t good at all (why I require thread if my application I don''t > > use it?, just to say something). > > I don''t know... it seems reasonable if they need to do something in a > threadsafe manner. Even e.g. Singleton needs synchronization, though it > doesn''t currently use Mutex to do it (IMO it _should_, fastthread > weirdness aside). > > I''m not really sure what the best resolution here is. fastthread is > ultimately intended to become a patch to Ruby core, of course. But that > can''t happen immediately, especially as even with the patch in hand I > would still need to sell the ruby-core folks on it... >I asked Eric Hodel about it, and he said it looked like the ''thread'' requirement in rubygems was added accidentally. That was after only a few moments of contemplation, so it may turn out differently in the long run.
On Dec 26, 2006, at 2:43 PM, Luis Lavena wrote:>> > > Er... you''re using fastthread in rake? Could I ask what for? I suppose > rake isn''t for long running tasks...Louis- I am not using fastthread directly for rake. But merb uses fastthread and I use rake to run the unit tests and rspec specs. So I guess this isn''t too big of a problem as it will just not use fastthread during testing. But I would feel better about my tests if they ran the exact same code as they run in production. Cheers- -- Ezra Zygmuntowicz -- Lead Rails Evangelist -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273)
On Wed, 2006-12-27 at 01:42 -0500, Wilson Bilkovich wrote:> I asked Eric Hodel about it, and he said it looked like the ''thread'' > requirement in rubygems was added accidentally. That was after only a > few moments of contemplation, so it may turn out differently in the > long run.Any updates on this since? -mental -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20061230/5aa328cb/attachment.bin
On Dec 30, 2006, at 12:36 PM, MenTaLguY wrote:> On Wed, 2006-12-27 at 01:42 -0500, Wilson Bilkovich wrote: >> I asked Eric Hodel about it, and he said it looked like the ''thread'' >> requirement in rubygems was added accidentally. That was after >> only a >> few moments of contemplation, so it may turn out differently in the >> long run. > > Any updates on this since? > > -mentalHey Mental- I have been talking with Eric Hodel about this and he had a suggestion. Maybe instead of requiring that fastthread be required before thread we should add the necessary Object.send :remove_const calls to remove Thread and Mutex and friends. would that work? I took the latest fastthread code and made these changes to the C code and recompiled. It seems to be working fine but I am not sure how to tell that fastthread is really loaded instead of thread. Here is what I did: # I removed this test: if (!RTEST(rb_require("thread"))) { rb_raise(rb_eRuntimeError, "fastthread must be required before thread"); } # and added these statements. rb_mod_remove_const(rb_cObject, rb_str_new2("Mutex")); rb_mod_remove_const(rb_cObject, rb_str_new2("ConditionVariable")); rb_mod_remove_const(rb_cObject, rb_str_new2("Queue")); rb_mod_remove_const(rb_cObject, rb_str_new2("SizedQueue")); This seems to work fine but I am unsure. Mental what do you think about this? Now instead of requiring fastthread after thread, we require thread and then require fastthread. Or since rubygems is already gong to require thread this takes care of it. It does seem better to allow fastthread to come after thread like this. In your test cases I also added require ''thread; before the require ''fastthread'' to make them work. How can we verify that this is a valid fix? Cheers- -- Ezra Zygmuntowicz -- Lead Rails Evangelist -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273)
On Sat, 2006-12-30 at 15:36 -0800, Ezra Zygmuntowicz wrote:> I have been talking with Eric Hodel about this and he had a > suggestion. Maybe instead of requiring that fastthread be required > before thread we should add the necessary Object.send :remove_const > calls to remove Thread and Mutex and friends. would that work?Ahh, it should. That will avoid messing with the classes of already created Mutexes etc. I can go ahead and do another fastthread release with that approach. -mental -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20061231/380b9621/attachment-0001.bin