[Mongrel] Recommentation: Sessions and PStore

Zed Shaw zedshaw at zedshaw.com
Sun Sep 3 14:34:00 EDT 2006

On Sun, 2006-09-03 at 11:48 -0600, Kirk Haines wrote:
> On 9/3/06, Zed Shaw <zedshaw at zedshaw.com> wrote:
> > Theorize all you want, but all I know is, use Mutex, process gets
> > killed, use Sync, process stays up.  Can't argue with the evidence.
> Sure I can.  Your conclusion about Mutex is like the conclusion once
> drawn about the sun.  It comes up in the east and goes down in the
> west, so the evidence clearly shows that the sun rotates around the
> earth, right?
> There is nothing wrong with Mutex.  It's an incredibly simple piece of
> code and can quite clearly be demonstrated not to leak.
> I'm not arguing with the fact that for some users simply swapping Sync
> in place of Mutex appears to clear a problem.  I'm just arguing with
> your conclusion that this is because Mutex is broken or because Ruby
> is leaking memory when it is used.

I like you Kirk, so don't take it personally, it's just an incredibly
sore spot with me since I've been complaining about this for ages and
everyone keeps telling me I'm crazy despite what I demonstrate.

But, explain this:




First one leaks, second one doesn't (with graphs even).  What's worse is
the inverse is true on win32.  These scripts have no Mongrel code, no
Rails code, they're just short Ruby scripts.

Now, it's not about users, it's about the two bug reductions that
simulate how Mongrel uses processes demonstrating a leak in both 1.8.5
and 1.8.4.  And it's insulting that you compare my careful examination
of the problem and numerous people's countless investigation into this
as nothing more than tribal Sun worship.  If anything the Ruby morons
(not you) running around ignoring Ruby's problems are the religious
fanatics who need to get a grip and fix this crap before guys like me
get fed up and run happily to a platform that doesn't suck.

It also has nothing to do with the Sun, Ptolemaic Astronomy, Polynesian
navigation by dead reckoning, or other stuff you read about in that one
speech/essay by Feynman about Cargo Cults.  I have evidence, many other
people reported the same results in different systems, and I have
demonstration scripts.  The only evidence other people have produced is
to write a different script that doesn't leak, which doesn't fix the
script that does leak.

Instead, the "garbage collection apologists" insist that it's not Mutex,
yet the change log for 1.8.5 says there were bugs in the GC code for
Threads.  I'm betting that it's not fixed, and that people like you who
keep arguing it's not a bug are doing nothing but making it so nobody
has to admit three things:

1) Threads suck ass in Ruby.
2) The GC sucks even worse.
3) Combining two forms of suckage makes for ultra suckage.

But hey, I've been over this a billion times with tons of people, and
all I get in response is that I'm totally wrong because someone else can
write a different script that doesn't leak.  Yet, this different script
doesn't fix the script that does leak given above.  It's a never ending
truly Ptolemaic cycle of Ruby on Ruby when the real problem is deep in
the morass of C code that makes up the wonderful split between Thread GC
and "everything else GC".

So, sorry Kirk, I'm not full of crap or making this up or anything else
you're implying.  I have demonstration code, I and others run the code
and it happens, I have graphs, statistics, measurements, and
demonstrated fixes.  Oh no, it's not Ruby, it's me.

Meanwhile, I don't even have time to go investigate the problem because
I'm trying to get this stuff out so people can do their jobs.  I'll
leave it to the apologists to argue that everything's just quite alright
and start looking for my next platform.

I hear Lua likes to fix their virtual machine.  Maybe I'll start there.

Again, sorry for ranting at you directly, but it really doesn't sit
right with me to have my careful measurements compared with ancient

Zed A. Shaw
http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.

More information about the Mongrel-users mailing list