It looks like I got too creative in 0.6.1 and consequently ran afoul of a bug in the Ruby interpreter. 0.6.2 works around the bug and should be entirely stable at this point.
Thanks to Young Hyun for his help in coming up with test cases.
== what?
fastthread is a Ruby library which provides a faster (and
non-memory-leaking) C implementation of the concurrency primitives from
stdlib's thread.rb. It aims to be 100% compatible with thread.rb's
public API.
So, how much faster? In the single-threaded case, fastthread's version
of Mutex#lock and Mutex#synchronize are comparable in performance to
Thread.critical= and Thread.exclusive. With multiple threads, it has an
additional advantage over Thread.critical in that entering a critical
section doesn't suspend any other threads unless they're competing for
the same lock. (Compare that to Thread.critical, which stops all other
threads dead!)
I know a lot of folks have been avoiding stdlib's Mutex because all the
method calls killed performance. But no more, with fastthread! Why use
Thread.critical when you can use the real thing?
== how?
Simply require 'fastthread' in addition to 'thread'. If you want to
make fastthread optional (recommended!), do it this way:
require 'thread'
begin
require 'fastthread'
rescue LoadError
end
This way, your program will still work on systems that don't have (or
don't need -- e.g. JRuby) fastthread, but you still get a performance
boost on systems where it's available.
== where?
Gem:
http://moonbase.rydia.net/software/optimized-locking/fastthread-0.6.2.gem
Tarball:
http://moonbase.rydia.net/software/optimized-locking/fastthread-0.6.2.tgz
fastthread is also available on Rubyforge (and therefore the main gems
repository), courtesy of the Mongrel project:
https://rubyforge.org/frs/?group_id=1306
-mental
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
