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
"define_method",:method_missing){|