Mongrel users - Feb 2007 - fastthread-0.6.4.1 released

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

== 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url :
http://rubyforge.org/pipermail/mongrel-users/attachments/20070214/fe9bdce2/attachment.bin

On 2/14/07, MenTaLguY <mental at rydia.net> wrote:
> == 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!).
>
<snip>
> == WHERE?
>
> Files are available from Rubyforge:
>
> http://rubyforge.org/frs/shownotes.php?release_id=9709
Following MenTaLguY release, I compiled and uploaded to rubyforge
win32 gem of fastthread.

Waiting it spread to all gem mirrors.

Later

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

> Following MenTaLguY release, I compiled and uploaded to rubyforge
> win32 gem of fastthread.
> 
> Waiting it spread to all gem mirrors.
Do you recommend using fastthread with mongrel/mongrel_service in
production on win32?

For that matter, I seem to recall you advocating against pen for load
balancing on win32. Do you have an alternate recommendation?

Thanks, and cheers.

- donald

On 2/15/07, Ball, Donald A Jr (Library) <donald.ball at nashville.gov>
wrote:
> > Following MenTaLguY release, I compiled and uploaded to rubyforge
> > win32 gem of fastthread.
> >
> > Waiting it spread to all gem mirrors.
>
> Do you recommend using fastthread with mongrel/mongrel_service in
> production on win32?
>
Yes, since any implementation of ruby 1.8 have the issues described by
MenTaLguY.
(even after several test win32 didn''t show leak described months ago by
Zed).

I recommend and been using it without troubles.
> For that matter, I seem to recall you advocating against pen for load
> balancing on win32.
>
The problem is cygwin and all the translation/compatibility layer. Pen is *nix.

Even if you see Pen on Windows (http://siag.nu/pen/). You sacrifice
performance due that extra layer around your processes.
> Do you have an alternate recommendation?
No, not yet. Guess until a serious option (without expending thousand
dollars in Windows Server 2003, which have built in support for this),
Pen will be the one.

Regards,

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

> The problem is cygwin and all the translation/compatibility 
> layer. Pen is *nix.
> 
> Even if you see Pen on Windows (http://siag.nu/pen/). You 
> sacrifice performance due that extra layer around your processes.
Sure, but that performance hit might be worth it if your rails webapp
serves occasional long requests, yes?
> > Do you have an alternate recommendation?
> 
> No, not yet. Guess until a serious option (without expending 
> thousand dollars in Windows Server 2003, which have built in 
> support for this), Pen will be the one.
As it turns out, this is running on win2k3, so that''s a possibility for
me. Can you point me towards more documentation on this option? Thanks
muchly.

- donald