[#796] Re: value of assignment (Re: Order of the value of an expression changed? (PR#579)) — Sean Chittenden <sean@...>
> sean@chittenden.org wrote:
Hi,
> |I have read the thread and I think this is a pretty bad change. I
Hi,
> > #BEGIN test.rb
Hi,
Hi --
Hi,
Hi --
Hi,
Hi,
Hi,
what about if attr_accessor :foo defined three methods - #foo, #foo=, and
> |What was wrong with having the receiver set the return value though?
Sean Chittenden <sean@chittenden.org> writes:
> > f = Foo.new()
>>>>> "J" == J Herre <jlst@gettysgroup.com> writes:
On 11 Feb 2003 at 11:13, Sean Chittenden wrote:
[#801] class of $1, $2 in 1.8.0 — dblack@...
Hi --
Hi,
Hi --
Hi,
Hi --
J.Herre <jlst@gettysgroup.com> writes:
Hi --
On Sat, 8 Feb 2003 06:52:17 +0900
Hi --
On Friday, February 7, 2003, at 03:15 PM, dblack@candle.superlink.net
[#851] Alternate GC ? — Mathieu Bouchard <matju@...>
[#875] OpenSSL for Ruby 0.2.0-pre0 — Michal Rokos <michal@...>
Hi everybody!
[#889] Bob Jenkins' hashing implementation in Ruby — Mauricio Fern疣dez <batsman.geo@...>
>>>>> "M" == Mauricio Fern疣dez <Mauricio> writes:
On Sat, Mar 01, 2003 at 08:42:40PM +0900, ts wrote:
>>>>> "M" == Mauricio Fern疣dez <Mauricio> writes:
On Sat, Mar 01, 2003 at 10:03:47PM +0900, ts wrote:
>>>>> "M" == Mauricio Fern疣dez <Mauricio> writes:
On Sat, Mar 01, 2003 at 10:10:35PM +0900, ts wrote:
Hi,
[#890] String and (repost) MemLeak — Michal Rokos <michal@...>
Hi,
Hi,
Hi,
Hi,
Hi,
Thread concurrency issue
Hello all,
I've been occasionally stumbled upon a strange problem with Ruby's
threads, that I cannot pinpoint its exact origin. I get occasional race
conditions where the Ruby interpreter consumes all my memory until the
Linux VM goes into action to kill processes (sometimes X11 too!!).
We use Ruby for our Web Application Framework all throughout the
hierarchy (from low-level HTTP handling to higher-level scripting). The
server uses multiple threads to service HTTP requests (one per socket).
Sometimes, and under no particular occasion, the server enters a 100%
CPU loop and consumes all memory until its death. We are taking all
necessary precautions (at least we think we do) to serialize access to
shared data and other critical sections of the code, using the Sync class.
What's interesting is that this exception pops up in our logs:
Sync_m::Err::UnknownLocker: Thread(#<Thread:0x2040e560 run>) not locked.
Taking a look inside sync.rb, this particular error occurs if the
blocking thread leaving a critical section doesn't hold the mutex/lock
anymore!!! Any ideas?
We are using Ruby 1.6.8 on Linux and AIX and the error appears (although
not in a reproducable manner) regardless of the platform used. Just for
the records, we use gcc-3.2 on SuSE 8.0 (Linux-2.4.18) and IBM's XLC 6.0
on AIX 5.2.
Thanks for your time, and sorry of this isn't the correct place to post
queries like this.
Elias