# Fastthread-0.6.4.1 released

**URL:** <https://www.ruby-forum.com/t/fastthread-0-6-4-1-released/85628>\
**Category:** Ruby\
**Created:** [February 15, 2007, 12:29am UTC](https://www.ruby-forum.com/t/fastthread-0-6-4-1-released/85628 "2007-02-15T00:29:57Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![MenTaLguY](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/439d5e/32.png) [@MenTaLguY](https://www.ruby-forum.com/u/MenTaLguY)\
**Post date:** [February 15, 2007, 12:29am UTC](https://www.ruby-forum.com/t/fastthread-0-6-4-1-released/85628/1 "2007-02-15T00:29:57Z")

</div>

== NOW

A new version of fastthread, the library providing better  
implementations of the classes in thread.rb, has been released.

Please note that fastthread is only for Ruby 1.8, not JRuby or any other  
Ruby implementation (most of them don’t need it anyway!).

== WHY

The existing implementation of Mutex, Queue, etc. in thread.rb is slow.

fastthread’s is faster (and bypasses the memory leak in Ruby 1.8’s  
Array#shift to boot).

This particular release fixes two issues in previous fastthread  
releases:

1. rb\_bug()s due to stale wait queue entries

2. an uninitialized variable warning on load

== HOW

To use fastthread, just require it in addition to ‘thread’. The API is  
identical to the existing classes, so you shouldn’t need to rewrite any  
code (so long as you’ve been respecting the public interface of those  
classes).

I’d recommend rescuing LoadError, to make it optional. (Remember, not  
all Ruby implementations need it!)

== WHERE?

Files are available from Rubyforge:

[http://rubyforge.org/frs/shownotes.php?release\_id=9709](http://rubyforge.org/frs/shownotes.php?release_id=9709)

== THE FUTURE

My hope is that fastthread won’t be needed for much longer – its code  
has been merged into ruby\_1\_8 as a build option (in which case, simply  
requiring ‘thread’ will get you the same stuff!), but there’s not been a  
fastthread-enabled release yet.

As for alternate Ruby implementations, JRuby already has its own  
implementation of the thread.rb primitives which uses native Java  
monitors, and I think we can expect other Ruby implementations to follow  
its lead.

But, until we get a new fastthread-ized 1.8 release, fastthread is still  
here for you.

Cheers,

-mental