From: Roger Pack Date: 2008-08-12T04:31:33+09:00 Subject: Re: ruby wish-list A thought on current_block_yield and then the GC: > It's not exactly the same, but couldn't you just define a > recursive map function? > > class Array > def map_r &block > map{|e|Array===e ? e.map_r(&block) : block[e]} > end > end > p [[1,2,[3]],[[[5],6],7],8].map_r{|e|e.to_s} > > => [["1", "2", ["3"]], [[["5"], "6"], "7"], "8"] Though a little hackish, I wonder if you can receive a named block then pass that block to itself, a la def map_r &block map{|e| block(e, &block) } end so that the block could itself call yield. But this would still be a little harder than being able to say current_block, should it be doable. Just thinking out loud. A question on the GC. So if you try and build a multi-threaded GC [one thread picks up on free objects, hands them back to the parent thread for use], it turns out that if you don't free memory, then my current GC does this: 1) you run out of freelist, so you call garbage_collect which spawns a child thread, and adds to the heap so the parent can continue. 2) when the child thread terminates the heap is now in a larger state than it was. 3) when it runs out of freelist again, it adds to the heap and spawns the child thread. The child thread now takes longer to finish than it did before. Meaning the parent will be adding more to heap while waiting for it to finish. 4) repeat 3 over and over until you run out of memory. So currently it doesn't free any memory ever [commented it out]. I'm hoping that adding that capability will do the trick. If that doesn't work, though, it seems possible for these two threads to become engaged in a cycle, if you ever get above a certain threshold then basically it will just eat up all the memory in the system as it takes longer and longer to collect. So it exacerbates the problem. Potential ways to beat this: never add to the heap during a garbage collect? Thoughts? Thanks! -R -- Posted via http://www.ruby-forum.com/.