Well, just when I thought I was out of the fastthread business…
Okay, in brief:
fastthread is a Ruby extension which re-implements the primitives in
Ruby’s thread.rb in C. It was merged into 1.8.6, replacing the old
thread.rb implementation, but the version that was merged had a couple
serious bugs.
So – now I release fastthread 1.0, which is basically the Ruby 1.8.6
version with the fixes applied. You can use it as a hotfix for 1.8.6
until the next 1.8.x version is released, and of course it should still
work for speeding up older versions of 1.8 as well.
Gems and source are available via the mongrel RubyForge project:
http://rubyforge.org/frs/?group_id=1306
Let me know if you guys have any more problems.
-mental
2007/3/20, MenTaLguY [email protected]:
version with the fixes applied. You can use it as a hotfix for 1.8.6
until the next 1.8.x version is released, and of course it should still
work for speeding up older versions of 1.8 as well.
Gems and source are available via the mongrel RubyForge project:
http://rubyforge.org/frs/?group_id=1306
Let me know if you guys have any more problems.
-mental
Hi Mental,
great stuff you’ve done here. Regarding 1.8.6, what happens if I
install fastthread and require it ? Will it be transparently ignored ?
All the code that I wrote ignores fastthread requires if it’s not
installed. But I’d still like it to behave correctly in the case
fastthread is installed on 1.8.6.
MenTaLguY wrote:
version with the fixes applied. You can use it as a hotfix for 1.8.6
until the next 1.8.x version is released, and of course it should still
work for speeding up older versions of 1.8 as well.
Gems and source are available via the mongrel RubyForge project:
http://rubyforge.org/frs/?group_id=1306
Let me know if you guys have any more problems.
-mental
The hot fix installed ok and your tests pass, but compilation had a
(probably insignificant) warning:
fastthread.c: In function ‘wait_condvar’:
fastthread.c:626: warning: passing argument 1 of ‘rb_ensure’ from
incompatible pointer type
This is gcc 4.1.2 on linux.
Do you happen to have a test case that reproduces the problems in the
pre 1.0?
Is there something ruby code can easily do (easier than running the test
case, that is) to detect whether it is running with the patched
fastthread or the buggy one?
On Tue, 2007-03-20 at 23:22 +0900, Jonas P. wrote:
great stuff you’ve done here. Regarding 1.8.6, what happens if I
install fastthread and require it ? Will it be transparently ignored ?
No, fastthread will get used in that case (which is probably what you
want, given that fastthread fixes bugs in 1.8.6).
All the code that I wrote ignores fastthread requires if it’s not
installed. But I’d still like it to behave correctly in the case
fastthread is installed on 1.8.6.
You shouldn’t need to make any changes at this point. Use fastthread if
it is installed. If there’s a version of Ruby it’s not appropriate for,
I’ll try to set the version requirements for the gem accordingly.
-mental
On Mar 20, 12:59 am, MenTaLguY [email protected] wrote:
version with the fixes applied. You can use it as a hotfix for 1.8.6
signature.asc
1KDownload
Do you have or will have a version for mswin32?
I have VC 8 rather than VC 6
These are the resulting messages/
Building native extensions. This could take a while…
ERROR: While executing gem … (Gem::Installer::ExtensionBuildError)
ERROR: Failed to build gem native extension.
ruby extconf.rb install fastthread
creating Makefile
nmake
Microsoft (R) Program Maintenance Utility Version 8.00.50727.762
Copyright (C) Microsoft Corporation. All rights reserved.
c:\ruby\bin\ruby -e "puts 'EXPORTS', 'Init_fastthread'" >
fastthread-i386-ms
win32.def
cl -nologo -I. -Ic:/ruby/lib/ruby/1.8/i386-mswin32 -Ic:/ruby/
lib/ruby/1.8/i38
6-mswin32 -I. -MD -Zi -O2b2xg- -G6 -c -Tcfastthread.c
cl : Command line warning D9035 : option ‘Og-’ has been deprecated and
will be remove
d in a future release
cl : Command line warning D9002 : ignoring unknown option ‘-G6’
fastthread.c
c:\ruby\lib\ruby\1.8\i386-mswin32\config.h(2) : fatal error C1189:
#error : MSC vers
ion unmatch
NMAKE : fatal error U1077: ‘"C:\Program Files\Microsoft Visual Studio
8\VC\Bin\cl.EXE
"’ : return code ‘0x2’
Stop.
Gem files will remain installed in c:/ruby/lib/ruby/gems/1.8/gems/
fastthread-1.0 for
inspection.
Results logged to c:/ruby/lib/ruby/gems/1.8/gems/fastthread-1.0/ext/
fastthread/gem_ma
ke.out
On Tue, 2007-03-20 at 23:42 +0900, Joel VanderWerf wrote:
fastthread.c: In function ‘wait_condvar’:
fastthread.c:626: warning: passing argument 1 of ‘rb_ensure’ from
incompatible pointer type
Yes, that’s harmless in this case.
Do you happen to have a test case that reproduces the problems in the
pre 1.0?
Not offhand. I think some of the tests which were added to ruby_1_8
cover the problems though.
Is there something ruby code can easily do (easier than running the test
case, that is) to detect whether it is running with the patched
fastthread or the buggy one?
The best thing to do is simply to require fastthread if it is available:
begin
require ‘fastthread’
rescue LoadError
end
The fastthread built into 1.8.6 is just “thread”.
-mental
Well, to be clear you should always be requiring ‘thread’ too. So the
very best practice with fastthread is this:
require 'thread'
begin
require 'fastthread'
rescue LoadError
end
i.e. simply add an optional fastthread require wherever you require
thread.
-mental
On Wed, 2007-03-21 at 06:45 +0900, bbiker wrote:
Do you have or will have a version for mswin32?
One should eventually be available. Unfortunately I do not have the
capability to build win32 gems myself; this is usually handled by Luis
Lavena of the Mongrel project. Hopefully he will have time to do so
soon.
As far as the VC6 versus VC8 thing goes, as far as I know the gem needs
to be built with the same version of VC as Ruby was built with. (it
sounds like your Ruby may have been built with VC6)
-mental
MenTaLguY wrote:
Well, to be clear you should always be requiring ‘thread’ too.
That got me thinking, and I eventually concluded the recommended
practice should be:
Do this:
require 'thread'
begin
require 'fastthread'
rescue LoadError
end
BEFORE you require 'thread' or anything that might indirectly
require
‘thread’ (e.g., drb).
If one just did a require ‘fastthread’, then a subsequent require
‘thread’ would undo it.
If messed up and did the “require ‘thread’ … require ‘fastthread’…”
AFTER requiring a file that did its own require ‘thread’, then there
would be a chance something in the interim used the un-augmented
‘thread’.
The safest thing, it seems to me, is to do the “require
‘thread’…require ‘fastthread’…” business at the very begining of
one’s application, if there’s a chance ‘thread’ is used anywhere.
All bets are off if “load” is used to directly or indirectly load
thread.rb. Surely nobody does that 
Of course, I could be missing something here. Thoughts?
On 3/20/07, MenTaLguY [email protected] wrote:
Well, just when I thought I was out of the fastthread business…
Okay, in brief:
fastthread is a Ruby extension which re-implements the primitives in
Ruby’s thread.rb in C. It was merged into 1.8.6, replacing the old
thread.rb implementation, but the version that was merged had a couple
serious bugs.
I wonder what those serious bugs might be.
I’m planning to install CentOS5 on some sixty machines. CentOS5 came
with a ruby-1.8.5 that had some nasty bugs, so I rebuild FC7
ruby-1.8.6-2 which has in ext/thread:
-rw-r–r-- 1 root root 24337 Mar 3 11:08 thread.c
If this version has serious bugs, I’d rather rebuild the libs with a
corrected thread.c than going to require fastthread all over the
place.
Cheers,
Han H.
On Wed, 2007-05-30 at 08:16 +0900, Dan Teitsort wrote:
If one just did a require ‘fastthread’, then a subsequent require
‘thread’ would undo it.
fastthread does require ‘thread’ itself, so that shouldn’t be a problem.
-mental
On Wed, 30 May 2007 20:42:29 +0900, “Han H.” [email protected]
wrote:
I wonder what those serious bugs might be.
Shortly, the waitlist structures could become corrupted.
I’m planning to install CentOS5 on some sixty machines. CentOS5 came
with a ruby-1.8.5 that had some nasty bugs, so I rebuild FC7
ruby-1.8.6-2 which has in ext/thread:
I’m not sure what version that corresponds to offhand. This version of
thread.c should be safe:
http://svn.ruby-lang.org/cgi-bin/viewvc.cgi/branches/ruby_1_8/ext/thread/thread.c?revision=12278
-mental
On 5/30/07, MenTaLguY [email protected] wrote:
I’m not sure what version that corresponds to offhand. This version of thread.c should be safe:
http://svn.ruby-lang.org/cgi-bin/viewvc.cgi/branches/ruby_1_8/ext/thread/thread.c?revision=12278
Ok, thanks, I’ll rebuild with that one.
Han H.