[Mongrel] [ANN] fastthread 0.6.2
lists at lastonepicked.com
Thu Jan 18 20:02:46 EST 2007
Sorry, for those of us that don't know, how does this relate to Mongrel?
I'm not really clear on that from your message.
Sounds cool though.
On Jan 18, 2007, at 4:51 PM, MenTaLguY wrote:
> 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
> 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
> 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
> threads dead!)
> I know a lot of folks have been avoiding stdlib's Mutex because all
> 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'
> require 'fastthread'
> rescue LoadError
> 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?
> fastthread is also available on Rubyforge (and therefore the main gems
> repository), courtesy of the Mongrel project:
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
More information about the Mongrel-users