From: Robert Klemme <shortcutter@...>
Date: 2006-07-07T05:01:25+09:00
Subject: Re: [BUG] thread/sync.rb memory corruption

2006/7/6, Ara.T.Howard <ara.t.howard@noaa.gov>:
>
> agreed.  this is actually the model i am using in the real code.  note that
> this code is simply a minimal example which triggers the bug.  regardless of
> whether it's a bad design or not (which it is) memory should not be corrupted
> by a simply ruby script - if so i think it's a bug.

Hm, I'm not sure I agree.  Try this one liner that will eventually
blow because too many threads are created that all wait for the mutex:

robert@fussel ~
$ ruby -r thread -e 'm=Mutex.new; m.synchronize { loop { Thread.new {
m.synchronize { } } } }'
[FATAL] failed to allocate memory

robert@fussel ~
$

This is not a Ruby bug but a but in the code.

> note that it's not that it simple gets slow that i'm showing - if you run
> under electric fence is shows actual memory corruption - same with valgrind.
>
> > Try my changes.  More and more threads queue up at the mutex.
>
> oh i know - that's how the real code works - with a Queue and a single thread
> consumer.

Good. You could also prevent notifications while notifying. Or store
notifications in a queue and loop as long in the notify method as
there are notifications in the queue.

> > Btw, it does not crash on cygwin - neither way. :-)
>
> huh.  suprising.  do you have electric fence?  you cannot make it crash
> without it unless you wait a very long time.

Please recheck that it's not the same situation I presented above. I
still have the feeling that this might be the real reason.

Kind regards

robert

-- 
Have a look: http://www.flickr.com/photos/fussel-foto/