[ANN] fastthread 1.0

[MenTaLguY]

--=-Gvz+QvI/3b4eVG08ZUuW
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

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=3D1306

Let me know if you guys have any more problems.

-mental

--=-Gvz+QvI/3b4eVG08ZUuW
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQBF/2otSuZBmZzm14ERAuvOAJ9yuP+qds2n/ft2ZJTyYtud9dtAJACgkhqz
ml7EsUIaFKiOR24iaUg/XDs=
=CRkA
-----END PGP SIGNATURE-----

--=-Gvz+QvI/3b4eVG08ZUuW--

 

[Jonas Pfenniger]

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

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.

 

[Joel VanderWerf]

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

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?

 

[bbiker]

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

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

 

[MenTaLguY]

--=-nsGXwKydz+56QqDs/tHg
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

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

--=-nsGXwKydz+56QqDs/tHg
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQBGAGkSSuZBmZzm14ERAmA5AKDb0mGDGlprqTyQJlgGCSB8B/1tlwCcDju1
QlQiYE4KleAo6LP5qWQv5c4=
=e7vL
-----END PGP SIGNATURE-----

--=-nsGXwKydz+56QqDs/tHg--

 

[MenTaLguY]

--=-NuvcNRti0PW6Ne9jDnuk
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

fastthread.c: In function =E2=80=98wait_condvar=E2=80=99:
fastthread.c:626: warning: passing argument 1 of =E2=80=98rb_ensure=E2=80= =99 from=20
incompatible pointer type

Yes, that's harmless in this case.

Do you happen to have a test case that reproduces the problems in the=20
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=20
case, that is) to detect whether it is running with the patched=20
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

--=-NuvcNRti0PW6Ne9jDnuk
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQBGAGnXSuZBmZzm14ERAh+eAKDXa1Pn1+mGItNuCvMJPyq1OBNdAgCgyY3p
/nQotmau31vIIypsp842NIw=
=ttf1
-----END PGP SIGNATURE-----

--=-NuvcNRti0PW6Ne9jDnuk--

 

[MenTaLguY]

--=-tQAKAgo26mFNN+HRRg5e
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

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
=20
i.e. simply add an optional fastthread require wherever you require
thread.

-mental

--=-tQAKAgo26mFNN+HRRg5e
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQBGAG20SuZBmZzm14ERAvgRAKDGUf76JVHW19qh+v49DBin5i+w/gCg2exS
ek6LHFIk1cCIEtmxpaGSXbk=
=AVDr
-----END PGP SIGNATURE-----

--=-tQAKAgo26mFNN+HRRg5e--

 

[MenTaLguY]

--=-lK+StVQPg4f+BM0ePLzD
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

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


--=-lK+StVQPg4f+BM0ePLzD
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQBGAG5+SuZBmZzm14ERAgl4AJ0dZz+20IK7HzFiBpC2zb6RV0lc8gCdF7Tx
8GmR8BOuBa8ILn7ihKK29XY=
=Rgg2
-----END PGP SIGNATURE-----

--=-lK+StVQPg4f+BM0ePLzD--

 

[Dan Teitsort]

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?

 

[MenTaLguY]

--=-lRPe+WqqY1WIrTO9wOKw
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

If one just did a require 'fastthread', then a subsequent require=20
'thread' would undo it.

fastthread does require 'thread' itself, so that shouldn't be a problem.

-mental

--=-lRPe+WqqY1WIrTO9wOKw
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQBGXOcPSuZBmZzm14ERAkhoAJsGFXd5U4skgxHjg8RP6+Fvu+12PgCgqo/u
XIs8EEEpRl4H4VhWdRQyclo=
=83Sr
-----END PGP SIGNATURE-----

--=-lRPe+WqqY1WIrTO9wOKw--

 

[Han Holl]

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 Holl

 

[MenTaLguY]

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

 

[Han Holl]

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 Holl