search for: mentalguy

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

...I have been doing anything I can to track it down. I already did the Mutex patch to use unshitf and pop instead of shift and push and it didn''t really help much. The mem leak only really shows up when you use the wsess option to httperf. The other day I saw a ruby C extension that Mentalguy built called optimized_locking. It has an OptimizedMutex class that is written in C. Its actually pretty small amount of C code and fairly easy to understand. Anyway, long story short, I patch the latest mongrel trunk and added this optimized_locking.c in as another C extension that gets...

Hi, A quick search didn''t explain what fastthread is, and how it relates to mongrel. Why would I want to install fastthread? Thanks, Joe

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

I''ve just committed fastthread 0.5.3, which finally gives us a working SizedQueue (which hadn''t really ever worked in previous versions). Mostly it was just a matter of refactoring Queue and SizedQueue into a single class behind the scenes, so I could move the signalling of the SizedQueue-specific condition variable inside the queue''s critical section. Failing to do so

With Mongrel 0.3.18, I have not seen a single one of the hangs that I have been grousing about for the past N weeks. Thanks MenTaLguY and Zed! Q: Mongrel loads fastthread, Mongrel loads Rails, Rails loads OCI8, OCI8 requires ''thread''. That means OCI8 is using fastthread too, right? Steve

I just realized -- if fastthread can be included while Mutex-using code is already running, then the definition and replacement of the classes needs to happen atomically. Otherwise, it creates a race condition where a thread can e.g. end up seeing an incompletely defined Mutex class or none at all. fastthread 0.6.1 addresses this by defining the classes and then atomically swapping the constant

Heya Folks- This is mainly for Zed and Mentalguy. I have been playing with the new release of rubygems 0.9.0.8 and I have a major problem with the requirement that fastthread needs to be required before thread. Just requiring rubygems and then requiring fastthread right after that will throw the error: ez _blog $ ruby require ''r...

Hey, campineros. And many good handshakes to zimbatm for getting some patches applied. So, yeah, I''d really like to get rid of any serious dependancies with this 1.6 release. Anything that''s not in stdlib has to go. Of course, camping-omnibus will still assume the whole ActiveRecord, Markaby, Mongrel setup that''s in the history books. Metaid can be removed and

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

I''m confused. Wasn''t threading fixed in 1.8.6, negating the need for fastthread? Why is fastthread still a requirement of Mongrel? Just curious. :)

I''ve just committed the makings of fastthread-1.0.2 to SVN, fixing a couple long-standing bugs in 1.0.1: - merged the fix from ruby_1_8 to avoid rb_bugging during exit with waiting threads - SizedQueue#enq is now defined properly Could you or whoever does the signed gems please turn the crank and upload the new gems? Thanks, -mental -------------- next part -------------- A

If there were a project to integrate Hobix with Camping, should it be called ShantyTown? Thanks, -mental

Just a quick note that I''ve committed the bits for fastthread 0.5; the most important differences are that all the thread.rb classes are once again marshallable, and we''ve got Luis'' commit which eliminates some warnings when building on Win32. -mental -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type:

I''m running a site that gets ~30k to 40k page hits per day. In the last 4 days my mongrel processes have been jumping into high CPU usage a couple of times a day to the point where my site becomes unresponsive (database on a diff machine with no load). The only way for me to resolve the problem and reduce load on the machine is to delete my rails cache directory (I have plenty of space

...release we make very soon. This pre-release is just to make sure that we didn''t step on any toes. Install it with: $ gem install fastthread --source=http://mongrel.rubyforge.org/releases $ gem install mongrel --source=http://mongrel.rubyforge.org/releases The fastthread gem implements mentalguy''s fastthread set of Thread locking alternatives. It is optional, so if it causes you problems, remove it from your gems: $ gem uninstall fastthread Restart Mongrel and all will be as it was before. The fastthread stuff will hopefully make Mongrel a little quicker and also reduce it...

...an effort to get Mongrel''s CGIWrapper to handle the mime type decoding as well. Full (lame ass svk style) ChangeLog is at http://mongrel.rubyforge.org/releases/ChangeLog It''s also tagged as 0.3.15 in svn for people who need that. The better explanation of the changes is: * Uses Mentalguy''s Optimized Sync for locking rather than Mutex or Sync. ***THIS BREAKS WINDOWS*** * Includes a monkey patched version of Mutex. If you see memory leaks, throw: require ''mutex_fix'' and see if they magically go away. * Still depends on the cgi multipart fix. I''...

Hi everybody, I would like to use ruby2ruby in a caming project, but there seems to be an incompatibility with camping, ruby2ruby and markaby. Unfortunately I receive strange Markaby::InvalidXhtmlErrors. To demonstrate, that only combination of all three components causes the problem I added the following code. I relies on Markaby and ruby2ruby only and works fine (a.k.a. as expected).

Hi guys, I''ve been running mongrel for a while now with Ruby 1.8.4, and last week upgraded to 1.8.6. Since upgrading, each morning when I wake up there''s a big problem: 1. Accessing the site returns a "500 Internal Server Error" 2. All the mongrel_rails processes are still running, but none of them are active (when I run top) 3. Lighttpd and pound are still

Quick note! fastthread 0.6.3 has been released to address a minor compatibility issue with ConditionVariable -- as with the original thread.rb, ConditionVariable can now be used with any mutex class implementing Mutex''s public interface. As before, gem and tarball available from RubyForge courtesy of the Mongrel project: http://rubyforge.org/frs/?group_id=1306 -mental --------------